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Abstract 

Future  USAF  operations  will  be  heavily  dependent  on  having  the  “right  informa¬ 
tion”  at  the  “right  time”,  and  Joint  Battlespace  Infospheres  (JBIs)  are  poised  to  fill  that 
role.  To  do  this,  JBIs  must  be  ubiquitous — always  accessible,  secure  and  responsive.  Of 
all  the  literature  written  regarding  JBIs,  the  most  important  problem  to  solve  in  order  to 
make  JBIs  work  in  mobile  scenarios  are  scalability,  reliability  and  adaptability  to  chang¬ 
ing  battlefield  conditions.  This  paper  explores  the  use  of  SBCast,  a  novel  adaptive  prob¬ 
abilistic  protocol,  a  delivery  mechanism  for  JBI  updates  and  as  a  possible  solution  to¬ 
wards  guaranteeing  these  qualities.  It  documents  tests  of  SBCast  within  a  simulation  en¬ 
vironment  configured  with  parameters  based  on  actual  military  field  operations.  From 
these  tests,  the  paper  examines  SBCast  as  an  enhancer  to  JBI’s  ability  for  overcoming 
transient  network  failures  while  managing  different  classes  of  subscribers  by  available 
bandwidth  and  priorities.  By  using  the  feedback  from  SBCast  as  a  middleware  layer  con¬ 
troller,  JBIs  would  be  able  to  “dial  up”  traffic  for  parts  of  the  network  and  “dial  down” 
traffic  in  others  based  on  dynamic  changes  in  network  congestion  or  traffic  demands. 
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ADAPTIVE  GRAVITATIONAL  GOSSIP  IN  MONITORING 

THE 

JOINT  BATTLESPACE  INFOSPHERE 


I.  Introduction 


1.1  Background 

The  idea  behind  the  Joint  Battlespace  Infosphere  is  to  tie  all  the  disparate  streams 
of  data  necessary  for  warfighters  -  to  mean  all  personnel  in  a  battle  zone,  from  intelli¬ 
gence  analysts,  supply  officers,  communications  units,  infantry,  tank  crews,  and  pilots  to 
general  officers  -  to  conduct  operations,  and  process  these  streams  into  one  useful  infor¬ 
mation  source  specifically  tailored  to  each  particular  warfighter’s  mission.  This  is  essen¬ 
tially  a  universal  interface  for  all  the  information  a  warfighter  needs,  and  thus  it  requires 
customizable  and  configurable  standard  interfaces  as  well  as  the  ability  to  interoperate 
with  both  currently  existing  and  future  information  systems.  Directly  from  the  executive 
summary  of  the  JBI  [25],  the  most  complete  definition  of  what  a  JBI  is  as  follows: 

The  Joint  Battlespace  Infosphere  (JBI)  is  a  combat  information  manage¬ 
ment  system  that  provides  individual  users  with  the  specific  information 
required  for  their  functional  responsibilities  during  crisis  or  conflict.  The 
JBI  integrates  data  from  a  wide  variety  of  detail  to  users  at  all  eche¬ 
lons...  [25] 

The  JBI,  being  one  of  the  cornerstones  of  future  USAF  operations  (per  the  USAF 
Vision  2020  and  Joint  Vision  2020),  is  aimed  at  allowing  our  forces  to  dominate  the 
Infosphere.  The  result  will  be  Information  Dominance  (one  of  the  USAF  core  competen- 
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cies),  where  forces  will  be  able  to  act  and  react  within  a  tighter  OODA  loop.  In  practical 
terms,  this  could  mean: 

•  Tighter  integration  with  sister  services  and  Allied  forces 

•  Correct  intelligence  with  exact  targets  to  strike 

•  Interrupting  the  Enemy’s  operations,  or  attacking  before  we  are  attacked 

•  Understanding  and  analyzing  the  Enemy 

Operationally,  the  JBI  is,  or  is  comprised  of,  command  and  control  (C2)  systems. 
Technically,  it  is  the  integration  of  all  these  C2  systems  linked  together  through  a  plat¬ 
form  of  various  protocols.  This  platform  consists  of  fuselets  to  process  and  aggregate  the 
different  streams  and  middleware  layers  to  translate,  interface  or  monitor  these  systems,. 
These  fuselets  would  all  wrapped  into  a  unified  publish-and-subscribe  (“pub-sub”)  sys¬ 
tem,  described  later. 

This  paper  proposes  a  possible  protocol  for  inclusion  in  use  for  JBI  as  a  controller 
middleware  layer.  This  novel  protocol,  known  as  Slack  Broadcast,  or  SBCast,  is  a  prob¬ 
abilistic  protocol  based  on  gossip.  The  use  of  a  gossip  protocol,  with  its  purported 
strengths  in  scalability,  speed  of  updates  and  use  for  pub-sub  systems,  could  provide  JBIs 
the  needed  gains  in  the  reliability,  scalability  and  availability.  The  next  section  defines 
and  explains  gossip,  and  how  it  could  extend  JBIs. 

1.2  Definition  of  Terms 

This  paper  discusses  the  use  of  a  customized,  optimized  gossip  protocol.  Because 
of  the  frequent  use  of  gossip  protocol  terms,  it  is  extremely  necessary  that  they  be  prop- 
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erly  defined  before  discussion.  This  section  includes  those  definitions,  and  explains  what 
these  mean  together.  More  importantly,  this  section  provides  a  brief  explanation  as  to 
what  a  gossip  protocol  means  to  JBIs. 

A  gossip  protocol  is  a  network-level  protocol  whose  purpose  is  to  propagate  up¬ 
dates  to  communications  nodes  in  a  network  by  randomly  selecting  the  next  recipient  of  a 
message.  This  is  where  it  gets  it  name;  the  underlying  idea  of  gossip  is  that  it  imitates 
gossiping  neighbors  in  a  community.  A  great  example  would  be  the  online  community  of 
customers  for  Apple  Computers  corporation  line  of  digital  music  players,  known  as 
iPods.  One  member  of  this  community  might  receive  some  especially  attractive  rumor, 
such  as  a  report  that  states  that  Apple  is  coming  out  with  a  new  portable  music  player  that 
is  smaller  than  a  stick  of  gum.  Meeting  with  his  peers  in  chat  rooms  or  in  email,  he  would 
mention  it,  resulting  in  randomly  updating  his  peers  through  casual  conversation. 
Through  these  random  updates,  the  news  about  the  new  music  player  travels  fast 
throughout  the  group. 

First  developed  by  A1  Demers  and  others  in  1987  [7],  the  first  basic  gossip  proto¬ 
col,  whose  initial  scheme  consisted  of  using  a  simple  random  function  (available  in  most 
implementations  of  C/C++),  has  diversified  into  a  whole  family  of  protocols.  These  pro¬ 
tocols  are  all  considered  gossip  because  they  vary  only  in  the  strategy  they  use  to  ran¬ 
domly  select  the  next  node.  For  example,  a  gossip  protocol  might  be  weighted,  in  that  its 
random  function  selects  the  next  recipient  by  some  criteria  associated  with  value.  For  ex¬ 
ample,  a  communications  node  might  have  a  higher  value  than  another  adjacent  node  be¬ 
cause  it  has  higher  bandwidth  connections,  and  would  most  likely  receive  updates  from 
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its  neighbors.  Another  might  use  a  different  probability  distribution  function  to  randomly 
select  a  recipient.  Instead  of  using  the  rand  ( )  function  from  the  C  libraries,  the  protocol 
would  use  some  probability  distribution  function.  Whatever  the  strategy  involved,  the 
common  denominator  amongst  any  gossip  protocol  is  that  it  is  probabilistic,  that  is,  its 
behavior  is  modeled  on  a  probability  distribution  function.  From  this  quality,  a  gossip 
protocol  is  known  as  an  epidemic  protocol;  the  behavior  of  gossip  is  likened  to  a  disease, 
where,  as  neighbors  infected  with  the  common  cold  might  bring  that  cold  to  other  neigh¬ 
bors,  communication  nodes  would  ‘infect’  each  other  with  updates.  Continuing  this  anal¬ 
ogy,  one  characteristic  that  affects  agents  in  a  gossip  network  is  its  infectivity,  the  prob¬ 
ability  that  it  will  send  updates.  Another  characteristic  is  an  agent’s  susceptibility,  the 
probability  that  it  will  accept  an  update.  Like  a  contagious  disease,  updates  spread  in  this 
way  propagate  rapidly  [4], 

This  paper  investigates  an  implementation  of  gossip,  referred  to  as  Slack  Broad¬ 
cast,  or  SBCast.  SBCast  was  developed  using  the  source  code  for  gossip  protocols  based 
on  Probability  Broadcast  (PBCast),  which  was  an  original  implementation  of  a  gossip 
protocol  and  was  developed  by  Kenneth  Birman  of  Cornell  University  [4],  PBCast  has 
given  birth  to  a  number  of  variants,  collectively  referred  to  as  the  *Cast  family.  Each 
member  of  the  *Cast  family  builds  upon  the  previous  one,  and  the  variants  differ  by  the 
addition  of  mechanisms  to  the  probability  calculation  and  the  factors  involved  with  that 
calculation.  These  factors  include  gravitational  weights,  a  priority  or  rating  given  to 
agents  in  the  gossip  network  according  to  observed  infectivity  or  susceptibility.  Being  no 
different,  SBCast  adds  the  mechanism  of  target  adjustment  to  the  calculations  accom- 


1-4 


plished  by  its  ancestors,  Gravitational  Gossip  (GWCast)  [3]  and  Adaptive  Gravitational 
Gossip  (AGWCast)  [13].  Some  of  these  calculations  are  based  on  interest  in,  or  priority 
of  members  to,  a  particular  type  of  update,  and  the  quality  of  bandwidth  available  based 
on  success  of  past  updates.  These  new  methods  of  calculating  protocols  based  on  net¬ 
work  conditions  make  the  *Cast  protocols  adaptive,  meaning  that  they  are  gossip  proto¬ 
cols  that  are  able  to  vary  update  rates  based  on  perceived  network  conditions.  SBCast  and 
its  relative  *Cast  protocols  are  discussed  in-depth  under  “Research  Approach”  and  ex¬ 
pounded  upon  in  Chapter  II. 

How  would  this  benefit  the  uses  of  the  JBI?  Gossip  protocols  have  been  key 
components  in  bulletin  board  systems  [3],  and  in  Chapter  II  it  will  be  shown  that  the 
publish-and-subscribe  software  architecture  is  a  major  design  component  for  JBIs.  The 
epidemic  nature  of  a  gossip  protocol  can  be  an  asset  in  deployed  ad  hoc  networks;  be¬ 
cause  a  gossip  protocol  is  inherently  decentralized,  segmentation  caused  by  the  instability 
of  links  can  be  compensated.  Therefore,  utilizing  SBCast  will  accomplish  a  number  of 
benefits.  First,  it  will  enhance  the  JBI’s  ability  to  overcome  transient  network  failures. 
Second,  it  will  allow  different  classes  of  subscribers  to  request  different  rates  of  traffic 
updates,  according  to  their  available  bandwidth  and  interest,  which  could  be  very  effec¬ 
tive  when  dealing  with  traffic  that  is  periodic  in  nature.  Finally,  the  gossip  feedback  from 
the  pub-sub  system  to  get  data  can  be  used  to  infer  current  network  conditions.  By  pro¬ 
viding  feedback  to  the  JBI  regarding  current  network  conditions,  it  will  be  able  to  adapt 
its  own  behavior  to  better  match  the  network’s  capacity  constraints.  Additionally,  because 
the  JBI  concept  envisions  use  in  various  sizes  of  networks  (small  to  large),  scalability  is  a 
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must  and  many  studies  have  shown  that  a  gossip  approach  scales  effectively  and  reliably 

[3]. 

1.3  Problem  Statement 

The  core  idea  for  this  thesis  is  using  SBCast,  a  novel,  adaptive  gossip  protocol  to 
monitor  publish/subscribe  and  quality  of  service  to  improve  reliability  and  scalability  of 
JBIs.  This  involves  determining  the  applicability  of  SBCast  to  an  actual,  military  envi¬ 
ronment  within  which  JBIs  would  be  deployed.  Therefore,  the  key  investigative  questions 
form  the  problem  statement,  are: 

•  Can  SBCast  be  applied  to  an  operational  JBI  Scenario? 

•  How  would  SBCast  perform  as  a  controller  component  in  JBI  middle¬ 
ware,  specifically  in  regards  to  scalability,  reliability  and  adaptability? 

Therefore,  the  purpose  of  this  thesis  is  to  evaluate  the  use  of  SBCast  as  a  middle¬ 
ware  layer  to  improve  the  reliability,  scalability  and  adaptability  of  JBIs. 

1.4  Research  Approach 

The  work  in  this  thesis  simply  follows  the  ongoing  research  started  by  Birman  in 
his  seminal  work  on  Gossip  in  1999  [4],  His  work  yielded  one  of  the  first  implementa¬ 
tions  of  a  gossip  protocol,  PBCast.  Since  then,  multiple  researchers  have  continued  with 
his  work.  From  that  base,  Hopkinson  and  others  went  on  to  define  GWCast,  a  *Cast  vari¬ 
ant  that  introduces  the  idea  of  “weights”;  that  is,  weighted  values  that  influence  which  of 
its  neighbors  a  node  in  a  PBCast  network  might  update  [3],  The  next  evolution  of  *Cast 
involved  adjusting  the  quality  at  which  updates  were  received—  raising  or  lowering  the 
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infectivities  in  order  to  utilize  bandwidth  more  efficiently  [13].  This  paper  adds  yet  an¬ 
other  iteration  to  the  *Cast  group  of  protocols—  the  technique  added  by  this  research 
work  involves  interpreting  the  quality  at  which  messages  are  received  (and  thus  indirectly 
the  bandwidth)  and  adjusting  the  gravitational  weights  for  a  node.  From  the  perspective 
of  evolution  of  protocols  based  off  of  PBCast,  this  paper  investigates  the  *Cast  family’s 
applicability  to  monitoring  JBIs. 

From  this  perspective  and  the  problem  statement,  the  key  investigative  question  is 
simply  how  well  does  SBCast  perform  in  a  JBI?  If  given  a  typical  scenario  that  reflects 
battlefield  conditions  in  some  way,  how  can  we  expect  the  protocols  to  behave?  This 
question  is  simply  answered  by  creating  some  controlled  environment  and  running  all  the 
*Cast  protocols  side-by-side  and  comparing  the  results.  The  next  logical  question  is  how 
the  experiments  can  demonstrate  how  SBCast  can  manage  the  bandwidth  by  controlling 
or  restricting  updates?  The  results  would  be  measurements  of  the  quality  of  the  updates. 
The  purpose  of  gossip  protocols  are  to  propagate  updates  in  publish-subscribe  systems 
using  methods  with  evenly  spread  overhead  and  probabilistically  high  reliability.  The 
successive  *Cast  protocols  enhance  basic  gossip  by  allowing  users  to  maintain  the  same 
properties  as  in  basic  PBCast,  but  with  the  ability  to  lower  the  expected  reliability  in  re¬ 
turn  for  lower  bandwidth  utilization.  If  the  new  protocol  can  maintain  the  promised  rate 
of  reliability  by  commensurately  lowering  the  bandwidth  required  then  the  protocol  is 
successful. 

As  for  creating  this  controlled  scenario  to  ran  the  protocols  side-by-side,  the  only 
practical  demonstration  would  be  in  a  simulation  test-bed.  Currently,  the  *Cast  protocols 
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source  code  has  been  developed  using  the  VINT  group’s  network  simulator,  ns-2,  and  ex¬ 
ist  as  objects  in  the  simulator.  This  ns-2  code  could  be  used  as  a  model  to  create  (but  not 
directly  translate  into)  source  for  an  actual  SBCast  implementation,  but  for  the  purpose  of 
this  research  ns-2  code  can  be  tweaked  and  modified  to  model  SBCast’ s  performance  for 
use  in  the  JBI.  This  approach  is  explained  in  greater  detail  in  Chapter  III. 

1.5  Scope  and  Limitations 

There  are  a  number  assumptions  and  limitations  that  constrain  the  scope  of  this 
paper.  These  constraints  deal  with  time  to  conduct  this  research,  and  other  constraints  in¬ 
volve  focusing  the  research  to  the  important  subject:  the  algorithms  involved  with  making 
SBCast  work  in  simulation.  Without  these  constraints,  what  research  that  was  accom¬ 
plished  would  be  unfocused. 

One  notable  limitation  is  the  matter  of  an  actual  wireless  network.  A  wireless  net¬ 
work’s  physical  characteristic  are  not  the  subject  of  this  paper;  so  considerations  for  the 
actual  physical  or  data  link  layers  in  the  OSI  protocol  stack,  such  as  the  use  of  IEEE 
802.11b,  g,  n  etc.  or  antenna  type,  signal  strength  or  other  characteristics  are  not  factored 
in  the  simulation.  Such  considerations  might  add  to  ns-2  processing  time,  and  would  add 
extraneous  factors  to  studying  SBCast’s  behavior.  To  simplify  matters,  in  the  network 
simulation,  the  nodes  are  stationary  and  links  are  considered  directional  (e.g.  similar  to 
duplex  links,  the  most  basic  link  available  in  the  ns-2  tool  set).  However,  to  simulate 
multi-directions,  meshes  are  employed  to  link  nearby  nodes  to  each  other. 
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Another  is  traffic,  which  is  considered  constant.  General  traffic  and  bandwidth 


usage  are  then  abstracted  and  represented  as  constant  bit  streams.  Likewise,  so  is  the 
content  of  JBI  traffic  (what  size  of  frames  or  packets  are  sent  to  the  actual  mission  data 
encoded),  which  is  considered  as  a  uniform  transmission. 

The  size  of  the  scenario  is  restricted  to  a  "local"  network  of  units  within  close 
proximity,  and  so  the  physical  size  of  the  JBI  network  simulated  covers  only  live  to  ten 
square  miles  of  battlefield,  with  ten  to  fifty  units  participating  as  subscribers  to  the  JBI 
services.  Although  the  original  documentation  envisions  JBIs  to  span  AORs  to  deal  with 
contingencies,  the  limits  of  ns-2  (see  below)  restrict  scale.  Additionally,  for  issues  of 
scale,  the  idea  of  a  JBI  is  that  it  can  be  composite  [23],  so  a  larger  JBI  can  be  a  collection 
of  smaller  JBIs  that  are  logically  constructed/disassembled  for  a  specific  task.  Therefore, 
the  results  for  a  larger  topology  can  be  inferred  through  experimental  results  of  a  smaller 
JBI  network. 

As  mentioned,  ns-2  has  problems  with  scale.  Besides  being  the  original  simulator 
environment  for  earlier  implementations  of  *Cast  protocols,  it  was  chosen  because  of  its 
modularity  and  “realism”.  However,  due  to  that  same  realism,  research  experiments  con¬ 
ducted  using  ns-2  tend  to  be  within  a  range  of  twenty  to  forty  nodes.  According  to  the 
Internet  Draft  Tools  for  P2P  Network  Simulation  [5] : 

"Due  to  the  realistic  nature  of  the  packet  level  NS2  simulator,  scalability  is 
a  major  issue.  However,  like  most  packet  level  simulators  NS2  can  run  in 
parallel  with  a  number  of  other  machines.  This  can  increase  the  maximum 
number  of  nodes  for  a  given  simulation  but  can  become  difficult  to  man- 
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age.  Subsequently,  NS2  is  commonly  used  for  simulating  small  networks 
and  is  generally  unsuitable  for  modeling  overlay  networks.  " 

This  characterizes  the  difficulty  with  using  ns-2  to  simulate  larger  networks  with 
substantial  amount  of  nodes.  Additionally,  there  are  some  design  choices  (discussed  in 
Chapter  V)  that  limit  the  speed  performance  of  the  *Cast  family  in  simulation,  tradeoffs 
that  yield  a  tighter,  more  comprehensive  gossip  model  but  result  in  longer  simulation  run¬ 
times  if  the  network  is  too  large. 

1.6  Summary 

This  chapter  covered  the  basis  of  this  research—  the  system  or  systems  of  JBIs,  the 
concept  of  probabilistic  protocols  and  specifically  the  *Cast  family  of  probabilistic  proto¬ 
cols,  and  the  basis  for  this  research.  The  successive  chapters  will  follow  the  research  out¬ 
lined  in  this  section.  Chapter  II  expounds  upon  the  background  by  outlining  and  summa¬ 
rizing  the  previous  works  in  this  field.  Chapter  III  will  outline  the  methodology  of  the 
experiments  used  to  compare  the  performances  of  each  of  the  *Cast  family  to  each  other 
and  to  SBCast.  Chapter  IV  will  provide  in-depth  analysis  of  the  results  of  the  experi¬ 
ments,  and  Chapter  V  will  summarize  the  previous  three  chapters,  draw  conclusions  from 
the  experiments  and  post  recommendations  for  future  research. 
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II.  Literature  Review 


2.1  Chapter  Overview 

This  paper  derives  the  use  of  Adaptive  Gravitational  Gossip  to  monitor  publish/ 
subscribe  functions  and  quality  of  service  Joint  Battlespace  Infosphere  (JBI)  systems  to 
improve  reliability  and  scalability  of  the  overall  collection  of  JBIs.  In  order  to  adequately 
address  this  problem,  this  chapter  lays  the  foundation  upon  which  to  build.  That  founda¬ 
tion  includes  a  description  of  how  JBIs  should  work  as  well  as  distributed  system  ideas 
and  concepts  that  play  into  JBIs,  and  the  current  research  involving  gossip  protocols. 

2.1  The  Problem  Domain:  JBI 

In  solving  any  problem  scientifically,  the  first  step  is  to  define  the  problem.  The 
first  literature  sources  reviewed  in  this  section  describe  and  define  the  concept  of  JBIs. 
These  papers  explain  what  JBIs  are,  their  key  objectives  and  describe  challenges  in  estab¬ 
lishing  JBIs,  and  give  an  overview  of  current  JBI  research. 

The  first  paper  and  foremost  of  research  involving  JBIs  is  by  Marmelstein,  and 
describes  the  overall  JBI  concept  and  the  idea  of  Force  Templates  [19].  His  paper  identi¬ 
fies  the  overarching  concept  of  JBI:  to  provide  ubiquitous  and  uniform  information  dis¬ 
semination  between  all  US  armed  forces  and  Coalition  allies,  and  to  do  so  in  a  way  that 
prioritizes  the  provided  information  by  relevancy,  mission  and  need-to-know  [19].  The 
JBI’s  purpose  is  to  address  the  barriers  to  information  sharing  among  coalition  military 
units.  Historically,  these  barriers  are  “stove  pipe”  systems  and  classification  issues.  The 
key  requirement  is  that  information  is  broken  up  into  discrete  pieces  which  are  easier  to 


2-1 


control  and  disseminate  to  various  entities  (information  customers,  which  could  be  any¬ 
thing  from  an  infantry  unit  to  a  logistics  office  to  a  tactical  fighter)  according  to  various 
requirements,  such  as  mission,  geographic  locale,  “need-to-know”,  classification  level, 
weapon  system,  or  priority.  The  chief  means  of  accomplishing  this  parceling  of  informa¬ 
tion  is  the  concept  of  “Force  Templates”,  the  idea  of  specifying  information  customers  or 
classes  of  customers  via  a  “template”  of  properties  (missions,  classification  level,  nation¬ 
ality,  priority,  etc)  and  providing  information  according  to  these  properties  via  a  publish 
and  subscribe,  or  pub-sub,  system  (defined  below).  The  force  template  would  provide  the 
context  and  policies  under  which  an  entity  would  interact  with  the  JBI.  The  overall  moti¬ 
vation  is  to  seamlessly  integrate  all  coalition  units  into  a  unified  Information  Infrastruc¬ 
ture  to  streamline  command,  control  and  intelligence  operations.  This  is  summarized  as 
“with  the  right  access,  provide  the  right  information  to  the  right  person  in  the  right  form 
at  the  right  time.”  Figure  2.1  diagrams  the  envisioned  capabilities  of  JBI  systems.  This 
paper  lays  down  the  requirements  for  JBIs,  but  does  not  go  into  implementation  details. 


Figure  2.1:  Organizational  Diagram  of  JBI 
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Satterthwaite  [23]  builds  on  Marmelstein’s  work  and  extends  the  Force  Template 
concept.  In  a  Satterthwaite’s  work  [23],  the  authors  develop  a  specific  force  template  to 
allow  individual  aircraft  to  become  subscribers  to  a  JBI.  Called  Guardian  Agent,  and  part 
of  the  Insertion  of  Embedded  Infosphere  Support  Technology  (IEST)  program,  the  sys¬ 
tem  addresses  the  specific  requirements  to  allow  an  aircraft  to  become  an  entity,  such  as 
how  it  links  up  and  receives  updates  from  a  JBI  via  currently  existing  and  future  hard¬ 
ware.  [23],  This  paper  provides  a  software  model  for  system  implementation  and  details 
interaction  among  physical  parts  of  a  network  by  which  an  entity  using  the  Guardian 
Agent  concept  can  interact  with  JBIs.  The  implementation  makes  use  of  Java  Remote 
Method  Invocation  (RMI).  A  Guardian  Agent  system  is  an  example  of  a  client  that  inter¬ 
faces  with  JBIs. 

Focusing  on  the  core  JBI  systems,  Combs  and  Linderman  [6]  addresses  the 
publish- and-subscribe  capability  of  such  systems.  The  key  contribution  of  their  work  is 
the  justification  of  the  rationale  for  pub-sub  systems  with  illustrative  example  code  using 
the  Java  language  and  Jini  technologies.  But  what  exactly  is  a  pub-sub  system?  Garlan 
and  Shaw  from  Carnegie  Mellon  University  describe  this  form  of  software  architecture  in 
a  document.  They  provide  a  working  definition  in  their  paper  describing  traditional  soft¬ 
ware  architectures  of  computers  and  networks,  many  still  in  use  today.  Referring  to  pub- 
sub  as  a  “blackboard”,  Garlan  and  Shaw’s  description  keys  in  on  the  intent  by  Marmel- 
stein.  In  their  article,  Garlan  and  Shaw  describe  the  blackboard  as  a  central  repository  of 
information,  which  could  be  composed  of  separate  knowledge  sources.  Using  the  system, 
users  could  write  to  some  common  blackboard  data  structure,  and  then  respond  opportu- 
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rustically  as  changes  are  made  to  the  blackboard  [10].  An  abstract  diagram  of  this  concept 
appears  in  Figure  2.2.  In  that  figure,  each  of  the  users  (ksl  through  ks8)  can  either  write 


Memory 


Figure  2.2:  Publish-and-Subscribe  Software  Architecture 


to  or  read  from  the  shared  data  asynchronously.  When  the  users  read  the  shared  data,  they 
are  subscribers  and  when  viewing  the  shared  memory  receive  updates.  When  the  users 
write  to  the  shared  data,  they  are  publishers  of  the  data  and  are  sending  updates  to  other 
users.  This  extends  upon  Marmelstein’s  vision,  which  considers  the  collection  of  JBIs  as 
a  central  repository  that  various,  heterogeneous  knowledge  sources,  such  as  fighter  air¬ 
craft,  tanks,  ground  units,  supply  depots,  intelligence  agents,  satellites  or  any  other  mili¬ 
tary  information  customer  can  access  and  update  information  critical  to  their  missions.  In 
addition,  this  formulation  as  a  blackboard  makes  the  overall  system  more  reliable  as  a 
distributed  system  because  the  central  repository  can  still  exist  and  be  reachable,  even  if 
it  is  only  intermittently  available  to  customers  suffering  adverse  network  conditions. 
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The  publish-and-subscribe  architecture  was  chosen  for  JBI  systems  because  it 
would  decouple  the  various  computer  and  communication  systems  that  would  make  up, 
or  interact  with,  JBIs;  provide  finer  granularity  and  control  of  information  released  via 
JBIs;  and  address  the  challenges  of  unreliable  or  connectionless  links  of  JBIs  as  distrib¬ 
uted  system.  Ultimately,  as  a  publish-and-subscribe  system,  entities  would  not  need  to  be 
connected  to  a  JBI  or  JBIs  at  all  times;  and  information  can  be  released  in  discrete  pieces 
per  the  requirements  laid  out  by  Marmelstein  [19].  Comb  and  Linderman’s  paper  then 
provides  an  implementation  of  core  publish-and-subscribe  capabilities  written  in  Java  and 
utilizing  Jini  [6].  Jini  is  a  service  architecture  for  Java  that  provides  network  devices  in 
distributed  environments,  with  a  network  level  plug  and  play  capability.  Unfortunately,  at 
the  time  of  publication,  experiments  using  this  code  were  not  published.  However,  the 
value  of  the  implementation  is  that  it  provides  a  schema  for  entities  to  interact  with  the 
JBI.  The  implementation  also  provides  logic  for  the  core  middleware,  independent  of  the 
quality  of  service  or  prioritization  issues  for  the  network  upon  which  the  entities  and  JBIs 
operate  [6].  As  such,  Combs  and  Linderman  illustrate  one  potential  form  of  the  protocols 
and  data  standards  that  will  be  employed  for  JBIs,  and  provides  more  detail  into  the  de¬ 
sign  philosophy  for  JBI. 

Loyall,  Lawson  and  Duzan  examined  Quality  of  service  (QoS)  issues  [18],  Their 
work  outlines  the  specific  quality  of  service  challenges  within  the  JBI  and  some  context/ 
example  scenarios  for  these  problems  as  well  as  proposed  solutions.  These  QoS  issues 
are:  timeliness  of  the  information,  precision  of  the  amount  of  data,  the  accuracy  of  the 
data,  the  importance  between  source  and  receiver,  and  trust  (security,  classification  and 
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need-to-know).  Loyall  also  discuss  where  the  means  of  monitoring  and  controlling  QoS 
can  be  placed  in  the  JBI  architecture.  Taking  these  into  account,  the  authors  [18]  state  that 
QoS  support  in  JBI  needs  sufficient  control  and  management  of: 

•  The  sources  of  information, 

•  The  infrastructure  for  transporting  information, 

•  The  users  of  the  information, 

•  The  competing  demands  of  multiple  information  exchanges,  and 

•  Dynamically  changing  environments,  e.g.,  requirements,  mission  modes, 
participants,  and  resource  availability  and  usage. 

As  this  paper  emphasizes  QoS,  with  a  special  emphasis  on  the  properties  of  prior¬ 
ity  and  need-to-know,  it  lays  down  the  particular  challenges  for  this  thesis  project. 

2.2  Distributed  Systems  Work 

Part  of  determining  solutions  to  the  challenges  described  in  the  JBI  problem  do¬ 
main  is  to  survey  the  current  offerings  for  distributed  systems.  In  verifying  whether  or  not 
a  gossip-based  solution  will  yield  desirable  results,  it  is  necessary  to  discuss  and  examine 
comparable  systems  and  how  they  might  address  the  problem  domain  differently.  Evalua¬ 
tions  of  gossip  versus  other  approaches  are  needed  to  see  if  it  introduces  concepts  or 
ideas  that  would  be  useful  in  optimizing  our  approach  or  avoiding  some  serious  pitfalls. 
Some  of  these  other  resources  also  provide  important  background  for  inter-related  ideas. 
Overall,  perspectives  from  these  other  approaches  should  give  an  excellent  vantage  point 
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to  observe,  compare  and  evaluate  SBCast’s  differences,  strengths  and  weaknesses,  and 
how  to  deal  with  them. 

An  excellent  distributed  system  with  which  to  compare  requirements  for  JBIs  is 
the  Astrolabe  system,  developed  by  Van  Renasse  with  Birman  and  Vogels  at  Cornell  [26]. 
It  is  designed  to  provide  information  from  a  collection  of  diverse  systems  spread 
throughout  a  wide-area  network.  Astrolabe  expresses  some  of  the  intent  of  the  require¬ 
ments  for  JBI.  One  use  the  authors  envisioned  the  ability  to  query  for  a  particular  file 
available  to  the  networked  systems,  regardless  of  the  node  that  physically  holds  the  file. 
Additional  uses  included  the  ability  to  configure  systems  to  report  the  status  of  members 
(uptime,  memory  available,  processors  available,  etc).  Astrolabe  is  similar  to  the  JBI  ar¬ 
chitecture  in  that  it  utilizes  SQL  queries,  which  have  support  in  many  vendors’  database 
client  programs,  to  communicate  using  a  reliable,  publish-and-subscribe  technique.  How¬ 
ever,  unlike  in  the  JBI,  Astrolabe  requires  significant  management  overhead  and  it  re¬ 
quires  central  management  servers,  similar  to  the  root  and  zone  servers  used  in  Domain 
Name  Service  (DNS)  in  Astrolable’s  most  straightforward  implementation  [26].  Both  of 
these  conditions  limit  Astrolabe’s  usefulness  in  ad  hoc,  wireless  environment. 

Since  monitoring  network  conditions  is  a  critical  part  of  this  research  paper,  one 
paper  by  Ji  and  Elwalid  discusses  an  interesting  technique  for  sending  updates  [15]. 
However,  what  makes  this  technique,  called  ‘network  inference’,  valuable  to  monitoring 
QoS  in  JBI  is  that  it  uses  measurements  based  on  multicast  messages  to  assess  the  state  of 
the  network.  What  this  means  is  that  network  inference  is  able  to  pass  updates  and  mes- 
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sages  amongst  its  nodes  without  sending  specific  network  status  protocol  packets.  As  a 
result,  the  noisiness  and  chatter  of  Gossip-based  protocols  is  significantly  reduced[15]. 

Another  good  example  of  a  distributed  system  geared  towards  monitoring  and 
controlling  a  network  is  the  system  described  by  Gjermundrod  et  al  [11].  It  employs  a 
status  dissemination  model  useful  for  modeling  the  spread  of  updates;  it  is  therefore  not 
using  a  strict  and  noisy  packet  stream,  but  instead  utilizes  the  semantics  of  status  data  to 
send  and  receive  updates.  What  this  means  is  that  each  subscriber  in  a  status  dissemina¬ 
tion  model  receives  an  update  and  derives  various  QoS  measurements  from  attributes  of 
that  update,  such  as  when  it  was  received,  who  it  was  sent  by  and  so  forth  [11]. 

For  direct  comparisons  with  Gossip  and  another  distributed  system,  Rodriguez  et 
al  provide  a  comparison  between  traditional  gossip  against  a  custom  protocol  called  Lola 
in  a  wide  area  network[22].  The  most  important  lesson  from  this  paper  is  the  weakness  of 
using  Gossip  or  any  other  probabilistic  protocol  in  a  WAN  because  gossip  tends  to  have 
high  latency  in  these  environments.  Rodriguez  then  designs  and  describes  Lola,  whose 
key  characteristic  is  that  it  builds  upon  gossip  by  enacting  a  weighted  update  scheme  that 
prioritizes  which  nodes  will  receive  updates  based  on  speed/bandwidth  available.  Al¬ 
though  the  author  emphasizes  a  distinction  from  gossip,  this  is  inherently  identical  to  the 
concept  of  a  weighted  gossip  protocol  such  as  GWCast  by  Hopkinson  et  al  [3]. 

A  project  that  is  analogous  to  JBI  efforts  is  the  Network- friendly  Epidemic  Mul¬ 
ticast  (NEEM)  project,  also  by  Rodriguez  [21],  NEEM  focuses  on  preserving  bandwidth 
and  keeping  costs  down  on  transmissions.  These  two  qualities  are  what  military  commu¬ 
nicators  are  seeking  to  enable  them  to  execute  network  operations  in  chaotic,  ad  hoc 
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wireless  environments.  The  paper  examines  different  criteria  for  buffer  management,  and 
concludes  that  a  semantic  approach,  which  provides  updates  and  messages  within  the 
protocol  itself,  such  as  a  placing  update  information  in  headers,  instead  of  placing  them  in 
a  message  payload,  works  best.  This  reasoning  is  similar  to  Ji  and  Elwalid’s  work  [15], 
where  both  Rodriguez  and  Ji  conclude  that  the  wrapping,  unwrapping  and  decoding  of 
messages  in  TCP  and  UDP  are  a  cause  of  unreliability.  Although  there  are  many  similari¬ 
ties  among  these  papers  and  focus  on  JBI,  the  problem  domain  differs;  Ji  and  Elwalid’s 
research  is  geared  towards  making  online  multiplayer  games  more  efficient.  The  intent 
and  overall  analogy  is  useful  because  the  requirements  for  the  game  are  similar  to  the  re¬ 
quirements  for  JBIs. 

2.3  Adaptive  Gravitational  Gossip  Background 

Finally,  after  building  upon  the  problem  domain  explanation  and  background  re¬ 
view  of  similar  distributed  systems,  the  next  task  is  to  fully  define  what  we  mean  by 
adaptive  gravitational  gossip  (extending  from  the  “adaptive  gossip”  definition  from 
Chapter  I),  and  to  examine  is  the  background  and  ongoing  research  in  its  area.  Studying 
these  resources,  we  can  note  what  has  been  explored  before,  and  extend  upon  it;  or  ex¬ 
pand  the  field  towards  areas  that  were  not  observed.  However,  knowledge  of  other  ex¬ 
periments  involving  gossip  within  the  perspective  of  the  problem  domain  will  provide 
valuable  insight  and  guidance  towards  formulating  research  and  working  towards  a  solu¬ 
tion.  More  importantly,  this  section  discusses  the  previous  experiments  and  characteris¬ 
tics  of  the  earlier  *Cast  protocols,  PBCast,  GWCast  and  AGWCast. 
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As  mentioned  in  the  Definitions  section  in  Chapter  I,  one  of  the  first  papers  to 
conceptualize  gossip  protocols  is  by  Kenneth  Birman  [4],  and  it  is  the  source  of  PBCast, 
the  original  epidemic  protocol  that  SBCast  is  derived  from.  Birman  conceived  PBCast  to 
be  an  asynchronous  system  that  is  both  scalable  and  reliable.  It  addressed  the  traditional 
distributed  system  issues  of  atomicity,  stability  and  scalability;  Birman  ran  numerous 
tests  to  demonstrate  this. 

Extending  on  Birman’s  work  on  Bimodal  Multicast,  Hopkinson  and  Jenkins  de¬ 
rived  the  concept  of  “gravitational  gossip”  in  a  successive  paper  [3],  Gravitational  gossip, 
or  GWCast,  was  a  protocol  where  the  probability  of  updates  going  to  a  node  was  based 
on  a  given  weight,  and  this  weight  was  derived  from  various  factors,  such  as  node  proc¬ 
essing  ability,  congestion  or,  in  the  context  of  this  paper,  available  bandwidth.  This  paper 
provides  some  preliminary  tests  simulated  in  a  lab  environment,  but  does  not  specifically 
address  a  problem  domain  [3]. 

Hopkinson  continued  work  on  GWCast  by  extending  it  and  adapting  it  to  a  spe¬ 
cific  problem  domain.  He  extended  the  idea  of  gravitational  gossip  by  making  it  adap¬ 
tive;  that  is,  the  weights  attributed  to  nodes  were  dynamically  adjusted  depending  on  cur¬ 
rent  network  conditions.  The  problem  domain  studied  the  power  grid  domain  examined 
by  Gjermundrod  [11].  The  result  was  the  next  version  of  *Cast,  AGWCast,  which  differs 
from  GWCast  with  it  use  of  adaptive  weights.  Hopkinson’s  paper  provided  further  tech¬ 
nical  and  implementation  details  for  building  an  adaptive  gravitational  gossip  system,  the 
same  details  that  will  be  used  for  the  systems  and  experiments  described  in  this  thesis. 
This  thesis  then,  extends  upon  Hopkinson’s  work  by  applying  adaptive  gravitational  gos- 


2-10 


sip  concept,  with  enhancements  produced  by  target  quality  adjustment  in  SBCast,  to  the 
JBI  problem  domain. 

Simultaneous  research  also  conducted  on  gossip  protocols  includes  an  “adaptive 
gossip”  protocol  by  Rodriguez  et  al  [22],  Rodriguez  compiles  a  compendium  of  existing 
gossip  implementations,  and  derives  a  technique  that  is  a  gossip  protocol  that  adapts 
based  on  the  resources  available  and  the  network  congestion.  This  technique  differs  from 
Hopkinson’s  [13]  because  it  is  not  weighted,  which  means  that  it  utilizes  the  age  of  a 
message  to  determine  where  to  send  updates. 

Another  related  work  that  chooses  a  problem  domain  similar  to  the  JBI  environ¬ 
ment  is  by  Qi  Zhang  and  Agarwal,  and  that  work  applies  gossip  to  ad  hoc  networks  [27]. 
In  that  paper,  the  researches  compare  multiple  approaches  to  the  probability  a  node  utiliz¬ 
ing  Gossip  would  update:  they  send  updates  based  on  a  counter,  according  to  network 
distance,  based  on  location  or  by  neighborhood  knowledge.  After  investigating  all  of 
these  variants,  the  researchers  introduce  a  new  hybrid  approach  that  combines  a  fixed 
value  with  a  counter  as  the  basis  for  the  gossip  probability  weights.  The  results  demon¬ 
strate  that  the  hybrid  approach  is  the  most  scalable  and  reliable,  and  also  provides  insight 
into  some  of  the  drawbacks  with  probabilistic  epidemic  approaches. 

Addressing  a  different  problem,  Jelasity  et  al.  consider  a  gossip  application  for 
peer  sampling  services  [23].  They  examine  the  scalability  of  gossip  by  measuring  its  per¬ 
formance  in  small  diameter  networks  to  large  clusters  of  nodes.  The  authors  analyze  the 
performance  of  gossip  in  complex  networks  with  statistical  physics  techniques.  Their  pa¬ 
per  thus  provides  a  useful  basic  analysis  of  gossip-based  networks[23]. 
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2.4  Summary 

This  chapter  has  summarized  important  work  related  to  gossip  protocols  and  JBIs. 
The  research  described  in  this  thesis  draws  on  the  previous  works  described  in  this  chap¬ 
ter,  introduces  new  concepts,  and  combines  and  formulates  the  sum  of  the  previous  con¬ 
cepts  described  here  into  a  proposed  schema  for  accomplishing  quality  of  service  and 
prioritization  for  JBIs  using  adaptive  gravitational  gossip. 
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III.  Methodology 


3.1  Chapter  Overview 

This  section  covers  the  methodology  used  to  create  and  explore  the  capabilities  of 
SBCast,  an  adaptive  gravitational  gossip  technique  based  on  AGWCast.  The  general 
problem  is  evaluating  SBCast  in  a  scenario  that  models  JBI  in  an  actual,  operational  envi¬ 
ronment.  The  research  approach  is  to  implement  SBCast  in  simulation  and  ran  experi¬ 
ments  on  this  simulation.  The  simulation  is  comprised  of  a  topology  representing  a  possi¬ 
ble  battlefield  network  of  units  as  JBI  subscribers  that  are  all  running  SBCast  as  the 
means  for  receiving  JBI  resource  updates,  and  various  conditions  used  to  test  SBCast’s 
reactions.  The  experiments  vary  by  changing  the  conditions  in  the  simulation.  This  is  to 
meet  the  objectives  of  the  experiment,  which  is  to  determine  if  the  SBCast  protocol  can 
maintain  the  quality  of  updates  despite  increased  or  reduced  network  conditions.  If  the 
quality  of  the  most  important  updates  can  be  maintained,  perhaps  at  the  cost  of  reducing 
the  bandwidth  available  to  less  important  information  streams,  then  this  will  allow  users 
to  make  best  use  of  the  total  bandwidth  available  according  to  their  own  priorities.  For 
perspective,  the  experiments  will  ran  trials  involving  SBCast  and  will  also  compare 
against  the  other  members  of  the  *Cast  family  (GWCast,  AGWCast  and  traditional 
PBCast).  This  chapter  discusses  the  formulation  of  the  problem,  describes  the  scenario 
used,  defines  SBCast  and  its  implementation,  discusses  about  the  experiments  and  proce¬ 
dures  used  to  execute  the  experiment,  and  outlines  the  development  of  the  code  to  make  it 
all  happen. 
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3.2  Problem  Description 

The  formulation  of  the  specific  problem  is  this:  given  a  local,  battlefield  arrange¬ 
ment  of  assets  (troops,  vehicles,  etc)  how  can  we  maintain  the  level  of  information  up¬ 
dates  despite  periodic  bursts  in  traffic  of  competing  background  traffic.  Towards  this  end, 
we  consider  forty-one  nodes,  which  can  represent  vehicle  units  or  troop  formations. 
These  nodes  are  connected  via  directional  or  directionless  wireless  links,  and  these  con¬ 
nections  are  not  only  shared  by  the  members  of  this  gossip  network  but  also  by  nodes  that 
are  not  running  *Cast  agents  but  who  contribute  to  the  overall  traffic.  The  scenario  can  be 
customized  to  create  a  specific  instance  of  the  problem. 

3.3  Scenario 

The  scenario  consists  of  three  components.  Its  purpose  is  to  simulate  a  possible 
formation  of  air  assets  in  order  to  accomplish  an  air  superiority  mission.  The  three  com¬ 
ponents  flesh  out  these  roles.  The  first  part,  the  topology,  represents  the  units  themselves, 
and  are  nodes  in  a  graph  that  represent  an  air  unit  (for  example,  A- 10  ground  support  air¬ 
craft  or  F-22  attack  aircraft)  running  a  *Cast  agent.  The  second  part  consists  of  the  links, 
or  edges,  in  the  graph.  The  nodes  and  the  links  form  the  full  graph,  and  represent  the 
logical  relationship  among  the  nodes.  All  the  nodes  receive  updates  in  this  arrangement, 
and  these  links  could  represent  directional  wireless  links,  such  as  a  direct  radio  transmis¬ 
sions  or  satellite  feeds.  The  third  part  of  the  scenario  is  the  set  of  data  streams  that  are  up¬ 
dated  via  the  *Cast  system.  These  application  streams  represent  the  JBI  in  the  scenario, 
and  all  nodes  subscribe  or  send  for  these  streams.  The  last  part  of  the  scenario  is  the  set  of 
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conditions,  which  represents  other  existing  network  traffic  besides  the  JBI  application 


streams.  Implementation  details  for  the  scenario  appear  in  Appendix  A. 
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Figure  3.1:  Scenario  Topology 

The  topology  appears  in  Figure  3.1.  Figure  3.1  is  a  simplified  view  of  the  dia¬ 
gram,  with  clusters  of  four  represented  by  the  bigger  icons.  These  clusters  are  referred  to 
as  group  levels  and  represent  like  units  meshed  together,  as  seen  in  Figure  3.2.  These 
group  levels  are  considered  to  be  in  close  proximity  with  each  other  and  share  the  same 
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Figure  3.2:  A  *Cast  Group  Level 
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interest  levels  in  JBI  application  groups  (see  below).  There  are  forty  standard  client  nodes 
and  one  sender  node  in  the  topology.  The  sender  node  pushes  out  *Cast  traffic,  and  all 
the  nodes  *Cast  agents  receive  it,  and  probabilistically  forward  the  updates  onward.  In 
ns-2,  all  the  notes  are  node  objects,  and  each  have  *Cast  agents,  software  that  represents 
the  JBI  application  streams  sending  out  the  *Cast  traffic,  or  receiving  and  forwarding  the 
*Cast  traffic  along  the  edges. 

Each  edge  is  a  logical  representation  of  some  sort  of  wireless  link,  whether  it  is  a 
radio  link,  satellite  link  or  a  combination  of  both.  In  the  figure,  thinner  edges  represent 
lower  bandwidth  links,  and  thicker  edges  represent  higher  bandwidth  links.  It  is  important 
to  note  that  edges  in  the  figure  represent  which  nodes  are  “closer”  to  each  other  and  thus 
the  direction  in  which  updates  arrive.  This  forms  a  logical  relationship  where  the  units 
communicate/relate  to  each  other  via  a  gravitational  gossip  protocol.  Additionally,  to  bet¬ 
ter  portray  a  wireless  network,  the  subgroups  within  the  gossip  groups  are  totally  con¬ 
nected  meshes.  Overall,  the  topology  is  strung  together  as  a  combination  star-mesh  net¬ 
work.  Finer  grained  detail  of  the  topology  can  be  found  in  the  expanded  diagram  in  the 
appendix  (Figure  B.l). 

As  mentioned  earlier,  each  node  subscribes  to  one  of  four  different  pub-sub  appli¬ 
cations,  or  groups  of  the  JBI.  Groups  could  also  be  considered  the  collection  of  all  the 
nodes  that  are  subscribed  to  the  same  pub-sub  application.  Subscription  means  that  the 
node  can  receive  and  read  incoming  updates,  and  publishing  means  being  able  to  write 
updates.  These  updates  represent  the  information  published  in  a  JBI;  for  example,  an  up¬ 
date  might  be  an  amendment  to  the  Air  Tasking  Order  (ATO),  or  the  status  of  forces  in  a 
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given  area.  On  the  other  hand,  updates  could  represent,  as  they  would  under  the  stated 
requirements  of  the  JBI,  an  update  of  an  already  existing  data  feed,  such  as  a  satellite  im¬ 
agery  stream  or  an  intelligence  database  query  result.  Groups  push  out  information  in  pe¬ 
riodic  bursts,  which  are  scheduled  and  predicted.  Periodic  bursts  originate  from  senders. 
In  this  topology,  the  only  sender  is  the  AWACS  (E-3)  in  the  center  of  the  topology.  A  col¬ 
lection  of  the  data  streams,  which  model  possible  group  applications  for  use  in  JBIs,  ap¬ 
pears  in  Table  3.1. 

Table  3.1:  Groups 


Group 

Name 

Description 

ATOI 

Air  Tasking  Order  Stream  #1 

Zone  assignment,  targeting  and 
mission  data;  important  to  fighter 
and  bomber  aircraft. 

AT02 

Air  Tasking  Order  Stream  #2 

Additional  information  not  included 
in  the  first  Air  Tasking  Order  stream 

CAS 

Combat  Air  Support  Data 

Specific  target  and  tasking  informa¬ 
tion  in  support  of  ground  forces; 
important  to  ground  support  aircraft, 
combat  rescue  and  troop  transpor¬ 
tation  aircraft. 

INT 

Intelligence  Imagery  Feed 

Provides  updates  to  a  satellite  and 
reconnaissance  imagery  data  re¬ 
pository;  important  to  reconnais¬ 
sance  aircraft  and  unmanned  aerial 
vehicles. 

Interest  is  a  characteristic  that  describes  the  priority  that  nodes  are  subscribed  to 
with  respect  to  a  given  data  stream.  Another  important  term  is  group  level.  Whereas  a 
group  refers  to  all  subscribers  to  a  given  information  stream,  the  group  level,  or  sub¬ 
group,  refers  to  a  subset  of  the  overall  group  with  its  own  level  of  interest  in  the  informa- 
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tion  stream.  For  example,  a  group  might  have  two  subgroups.  The  first  subgroup  might 
be  interested  in  receiving  roughly  half  of  the  overall  updates  while  the  second  subgoup 
might  only  wish  to  receive  a  quarter  of  the  information  updates.  Interest  appears  in  Table 
3.2.  Each  column  represents  a  particular  unit/agent,  and  each  row  denotes  that  interest  to 
the  data  stream  as  a  percentage.  The  greater  the  percentage,  the  most  likely  a  node  will 

Table  3.2:  Interest  Levels 


Unit/ 

Agent 

w 

F-22 

A-10 

F-18 

AH-64 

UH-60 

E-3 

RQ-1 

RQ-8 

ATOI 

80 

70 

70 

65 

65 

75 

60 

60 

AT02 

80 

70 

70 

65 

65 

75 

60 

60 

CAS 

50 

80 

65 

85 

90 

35 

35 

55 

INT 

50 

45 

65 

66 

66 

80 

90 

85 

receive  and  pass  on  a  message  from  that  particular  stream.  Also  referred  to  as  target 
qualities,  for  GWCast  and  AGWCast,  the  target  qualities  are  constant.  For  SBCast,  the 
technique  is  to  lower  or  raise  the  target  qualities  by  the  status  of  the  network,  so  these 
fluctuate  as  interest  in  each  specific  data  stream  waxes  and  wanes  with  changes  made  by 
the  protocol.  In  other  words,  interest  is  dialed  up  and  down  depending  on  the  heuristic 
used  by  SBCast. 

The  last  part  to  be  modeled  is  the  simulation  of  traffic  other  than  the  JBI  applica¬ 
tion  streams.  Referred  to  as  the  network  traffic  conditions,  these  represent  other  data 
transmissions  that  occur  in  the  battlefield.  Sampling  real  world  traffic  would  be  too  com- 
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plex  and  varied,  and  would  result  in  longer  simulation  ran  times  or  inconsistent  results. 
The  controlled  environment  requires  only  that  there  are  high  or  low  levels  of  traffic. 
Therefore,  the  way  these  conditions  are  handled  in  the  ns-2  simulation  is  as  a  set  of  con¬ 
stant  bit  rate  (CBR)  traffic  generators  at  each  node  for  each  link.  These  CBRs  can  be 
turned  off  and  on  to  simulate  transmissions  occurring  at  each  node,  and  turning  on  more 
CBRs  can  simulate  more  traffic. 

To  create  rolling  waves  of  traffic,  the  CBRs  are  turned  on,  one-at-a-time,  at  peri¬ 
odic  intervals.  For  example,  at  500  ms  one  CBR  is  turned  on.  At  1000  ms,  the  next  is 
turned  on,  and  so  fourth.  This  would  occur  until  all  the  required  CBRs  for  the  network 
traffic  condition  are  on  and  transmitting  data.  Once  all  the  CBRs  are  active  on  all  links, 
the  scenario  will  continue  for  a  set  time.  After  that  period  is  over,  the  traffic  will  recede, 
and  this  is  done  by  simply  turning  off  each  CBR,  one-by-one,  until  all  the  links  are  free 
does  this. 

Figure  3.3  illustrates  the  steps  of  this  procedure.  It  shows  successive  views  from 
the  ns-2  network  animator  (nam)  user  interface,  nam  is  a  tool  that  is  used  to  visualize  ns- 
2  simulation  events.  Here,  it  is  used  to  illustrate,  on  a  simple  example  mesh  network,  the 
gradual  activation  of  the  CBRs.  Figure  3.3a  shows  the  ns-2  graph  where  no  CBRs  are  ac¬ 
tive;  Figure  3.3f,  on  the  opposite  end,  shows  the  graph  when  all  CBRs  are  active.  One 
CBR  is  turned  on  a  link  towards  the  start  of  the  simulation,  as  shown  in  Figure  3.3b,  and 
successively  CBRs  are  each  link  are  turned  on,  gradually  building  the  number  of  CBRs 
active  (Figures  3.3c,  d  and  e)  until  finally  all  links  are  active  in  Figure  3.3f.  For  recessing 
the  traffic,  the  scenario  needs  to  only  script  events  to  occur  in  the  reverse  order,  from 
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Figure  3.3b:  One  CBR  Starts 
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Figure  3.3f:  All  CBRs  Active 


Figure  3.3:  Progression  of  Network  Conditions 
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Figure  3. 3 f  back  to  3.3a.  This  is  the  basis  for  the  network  conditions  in  the  experiment. 
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3.4  The  Novel  Protocol:  SBCast 


The  novel  protocol  and  subject  of  this  paper  is  called  SBCast.  It  is  a  variant  of  the 
*Cast  protocols,  and  evolves  directly  from  AGWCast.  SBCast  is  a  descendant  of  PBCast, 
and  thus  retains  qualities  of  PBCast,  GWCast  and  AGWCast.  As  a  result,  SBCast  is  simi¬ 
lar  to  its  *Cast  family  members;  it  is  probabilistic  per  PBCast,  it  prioritizes  updates  via 

1  AGWCast :: recv (packet) 

2  round  / /  current  round  we  are  in 

3  weights 

4  targets 

5  if  packet  is  of  type...  //  other  cases 

6  end-if 

7  if  packet  is  of  type  timer 

8  update  round 

9  send  weight  updates 

10  end-if 

12  if  packet  is  of  type  weight  update 

13  evaluate  weight  updates 

14  evaluate  targets 

14  recalculate  weights , targets 

15  end-if 

1 6  End 


Figure  3.4.  Original  Simplified  AGWCast  recv  ( ) 
gravitational  weights  in  the  same  exact  technique  of  GWCast,  and  also  incorporates  the 
adaptive  gravitational  algorithm  of  AGWCast. 

The  difference  that  sets  SBCast  apart  is  the  “slack”  routine  it  adds  to  the  *Cast 
protocols  current  behavior.  The  idea  behind  SBCast’ s  slack  routine  is  to  lower  the  target 
qualities  for  the  nodes  so  that  they  can  send  updates  more  easily.  SBCast  stands  for 
“Slack  Broadcast”,  and  its  name  derives  from  this  technique  of  lowering  the  targets  (giv¬ 
ing  slack)  to  enable  the  protocol  to  “catch  up”  by  backing  off  on  the  intended  probability 
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1  SBCast :: recv (packet) 

2  round  / /  current  round  we  are  in 

3  weights 

4  targets 

5  if  packet  is  of  type...  //  other  cases 

6  end-if 

7  if  packet  is  of  type  timer 

8  update  round 

9  send  weight  updates 

10  end-if 

12  if  packet  is  of  type  weight  update 

13  evaluate  weight  updates 

14  evaluate  targets 

15  TargetStrategy : : adjust_targets 

16  recalculate  weights (weights , targets ) 

17  end-if 

1 8  End 


Figure  3.5:  recv  ( )  Modified  For  SBCast 

of  sending  updates.  Once  the  updates  have  caught  up,  through  slowed  rate  of  updates  or 
increased  bandwidth,  the  target  qualities  are  restored  at  a  rate  commensurate  of  the  re¬ 
stored  bandwidth.  This  can  be  also  described  as  “backing  off.”  SBCast  agents  at  different 
nodes  sense  network  conditions  in  their  part  of  the  network,  and  by  coordinating  with 
their  peers  within  the  same  group  level,  “back  off’  of  their  original  intended  target  quali¬ 
ties  and  accept  sending  messages  at  lesser  rates  in  order  to  allow  bandwidth  usage  to 
clear  up.  Flowever,  the  intent  is  not  to  simply  turn  off  outgoing  traffic.  This  defeats  the 
purpose  of  making  the  application  services  reliable.  Instead,  the  objective  is  to  maintain 
an  expectation  of  updates,  albeit  at  some  reduced  rate.  This  expectation  is  expressed  as  an 
observed-to-target  ratio,  which  is  a  ratio  of  the  observed  infectivity  to  the  target  quality. 
By  maintaining  this  ratio,  SBCast  will  be  able  to  maintain  an  expectation  of  receiving 
updates  proportionate  to  the  original  priorities  required  for  a  given  subscriber. 
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Figure  3.6:  UML  For  SBCast  Target  Strategy 


Implementation-wise,  adding  SBCast’s  capability  to  the  *Cast  source  involved 
adding  a  call  to  a  subroutine  to  the  algorithm  that  handles  the  receipt  of  packets.  Figure 
3.4  and  3.5  illustrate  this  convergence. 

Basically,  the  first  block  of  pseudo-code  (Figure  3.4)  shows  AGWCast’s  general 
algorithm:  the  recv  ( )  routine.  The  recv  ( )  is  a  common  method  call  for  protocols 


implemented  for  ns-2,  and  it  is  the  method  called  when  an  agent  in  an  ns-2  simulation 
must  deal  with  an  incoming  packet.  The  second  block  (Figure  3.5)  shows  the  changes  (in 
bold)  that  were  made  to  that  original  algorithm  to  create  the  recv  ()  for  SBCast.  The 
change  is  an  addition  of  a  call  to  a  subroutine,  but  with  a  subtle  twist.  That  twist  is  that 
this  new  subroutine  for  SBCast  is  implemented  as  a  software  engineering  design  pattern 
known  as  a  strategy  pattern.  A  design  pattern  is  an  often-repeated  pattern  of  code  that  has 
been  used  repeatedly  and  successfully  in  numerous  software  programs  due  to  its  ability  to 
increase  flexibility,  performance  or  reuse  [2].  A  strategy  pattern  is  a  software  engineering 
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design  pattern  that  encapsulates  a  commonly  used  subroutine  into  a  separate  object,  or 
strategy,  so  that  either  the  strategy  can  be  used  again  and  separately  later,  or  that  a  differ¬ 
ent  strategy  can  be  interchanged  in  the  original  call  from  the  original  routine  to  the  sub- 

1  HistoricalTargetStrategy : : adjust_targets (curr_infectivity , 

curr_susceptibility , curr_target) 

2  history  :=  new  array 

3  rates  :=  new  array 

4  adjustments  :=  new  array 

5  min_slots  :=  10 

6  threshold  :=  0.005 

7  best_target 

8  history. add  curr_infectivity 

9  rates. add  curr_susceptibility 

10  if  (history . size , rates . size  or  adjustments . size  <  min_slots) 

11  adjustments . add  curr_target 

12  return  curr_target 

13  else 

14  if  (almost  all  history  less  than  curr_target) 

15  new_target  :=  history. max 

16  else  if  (more  than  half  rates  <  rates . average) 

17  if  (rates  going  down) 

18  new_target  :=  curr_target+ (best_target-curr_target) /2 

19  else  if  (best_target<history .max  or  rates . avg< threshold) 

20  new_target  :=  best_target 

21  else 

22  new_target  :=  curr_target  +  (best_target  - 
curr_target) /min_slots 

23  end- if 

24  else 

25  new_target  :=  curr_target 

26  end-if 

25  adjustments . add  new_target 

26  return  new_target 

27  end-if 

28  end-if 
28  End 


Figure  3.7:  SBCast  Historical  Target  Strategy 
routine  [12],  In  this  case,  SBCast’s  capability  is  encapsulated  in  the  call  to  ad- 
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just_targets  and  a  strategy  object.  The  new  form  for  the  *Cast  code  appears  below, 
in  a  simplified  UML  format  in  Figure  3.6. 

The  net  result  is  that  any  target  adjustment  can  be  defined  and  substituted  into 
SBCast,  altering  SBCast’s  behavior.  For  example,  in  Figure  3.6  there  are  three  strategy 
subclasses  defined:  the  Null  Target  Strategy,  Simple  Target  Strategy,  and  Historical  Target 
Strategy.  Null  Target  has  a  method  adj  ust_targets  that  does  nothing;  Simple  Target 
Strategy  has  an  adj  ust_targets  that  adjusts  target  qualities  based  on  the  last  round 
of  data  observed.  These  two  strategies  were  developed  prior  to  Historical  Target  Strategy, 
the  actual  strategy  used  for  these  experiments  and  explained  in  the  next  paragraph.  Be¬ 
cause  all  three  classes  are  subclasses  of  the  type  TargetStrategy,  by  Liskov’s  principle, 
which  states  that  any  subclass  of  a  class  with  identical  interfaces  for  identical  methods, 
can  substitute  for  that  superclass  [17]  any  one  of  these  target  adjustment  strategies  can  be 
used  by  SBCast.  The  strategy  patterns  opens  up  numerous  avenues  for  future  research,  of 
which  some  are  explored  in  Chapter  V.  This  architectural  change  is  what  makes  SBCast 
different  from  its  relatives:  it  adds  an  additional  step  of  adjusting  targets  between  reading 
network  conditions  and  recalculating  gossip  weights,  and  encapsulates  this  behavior  in  a 
strategy. 

Although  different  target  adjustment  strategies  could  be  employed,  this  experi¬ 
ment  used  what  is  termed  a  historical  approach.  The  algorithm  is  illustrated  in  pseudo¬ 
code  in  Figure  3.7. 

The  premise  of  the  historical  approach  is  to  observe  a  number  of  rounds  (a  “his¬ 
tory”)  and  make  a  decision  to  adjust  target  qualities  based  on  those  observations,  re- 
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corded  as  “slots”  in  that  history.  The  observations  involve  looking  for  rising  or  falling 
trends  in  observed  infectivities  and  susceptibilities.  From  these  observations,  the  algo¬ 
rithm  adjusts  the  target  quality  in  one  of  three  different  ways: 

•  Adjust  down  to  the  best  observed  infectivity 

•  Adjust  up  to  the  original  target  quality  divided  by  the  number  of  slots 

•  Adjust  up  to  half  of  the  original  target  quality 

The  algorithm  was  designed  to  back  off  aggressively  but  recover  gradually.  This 
technique  should  allow  an  immediate  reaction  to  significant  losses  of  bandwidth  and  re¬ 
duce  churning  up  the  network  once  bandwidth  is  restored.  This  way,  sudden  losses  are 
addressed  while  newly  recovered  bandwidth  is  utilized  gradually  and  not  hoarded  by  a 
single  group  level.  The  result  of  employing  this  algorithm  should  result  in  a  gradual  re¬ 
covery  of  the  observed-to-target  ratio.  The  results  of  these  experiments  will  verily  if  this 
is  the  case. 

3.5  Experiments 

Tests  consist  of  ten  runs  of  different  network  traffic  conditions  and  cases  based  on 
the  above  scenario.  Due  to  ns-2’s  long  run-times  using  the  scenario  outlined  above,  each 
test  will  be  run  for  400  seconds  of  simulated  time.  Each  test  is  repeated  ten  times.  Each 
test  run  is  executed  over  a  scenario  with  one  of  the  specified  network  conditions  and  one 
of  the  listed  cases.  There  are  three  different  types  of  network  conditions  and  four  different 
cases,  as  explained  below. 
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The  three  conditions  differ  in  the  set  of  CBRs  that  are  turned  on,  as  described  in 


the  scenario  section.  To  create  a  situation  where  network  bandwidth  will  be  increasingly 
utilized  at  a  constant  rate,  the  CBRs  are  turned  on,  one  at  a  time  in  that  set,  until  all  the 
CBRs  are  on  and  bandwidth  is  saturated.  Then,  to  decrease  the  traffic  uniformly,  the 
CBRs  are  periodically  turned  off  one-by-one.  Each  traffic  condition  is  specified  as  fol¬ 
lows: 

•  Wide  bandwidth  links  saturated.  The  links  with  the  higher  amounts  of  band¬ 
width,  which  also  form  the  backbone  of  the  topology,  become  saturated—  that  is,  waves 
of  interference  (or  other  traffic)  are  flowing  across  the  topology,  limiting  the  bandwidth 
available  between  group  levels. 

•  Narrow  bandwidth  links  saturated.  Similarly,  the  links  with  lower  bandwidth 
suffer  from  these  same  waves  of  background  traffic.  These  links  are  the  edges  within  a 
group  level.  This  traffic  condition  limits  nodes  connectivity  to  each  other  within  their 


Table  3.3  Experiments 


Wide  Bandwidth 
Links  Saturated 

Narrow  Band¬ 
width  Links  Satu¬ 
rated 

All  Links  Satu¬ 
rated 

PBCast 

Test  1 A 

Test  2A 

Test  3A 

GWCast 

Test  1 B 

Test  2B 

Test  3B 

AGWCast 

Test  1 C 

Test  2C 

Test  3C 

SBCast 

Test  1 D 

Test  2C 

Test  3D 

own  group  levels. 
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•  All  links  saturated.  Combining  aspects  of  the  first  two  conditions,  this  condition 
basically  sends  waves  of  interference  throughout  the  entire  network.  All  CBRs  are  on  in 
this  condition,  and  this  should  prove  to  be  the  greatest  challenge  to  the  *Cast  protocols. 

These  conditions  are  then  used  to  vary  the  cases,  whose  controlling  variable  is  the 
type  of  the  gossip  protocol  used.  These  cases  are: 

•  PBCast  -  The  original  implementation  of  Gossip  will  be  used.  This  will  serve  as 
a  baseline  for  the  performance  of  the  other  *Cast  protocols  and  validate  the  experiments 
run  on  these  protocols  in  previous  papers.  In  this  case,  the  agents  have  equal  probability 
of  updating  any  of  the  other  agents.  For  implementation  purposes,  this  means  that  all 
interest  levels  are  set  at  98%. 

•  GWCast  -  The  nodes  all  run  GWCast  agents,  which  differ  from  PBCast  only  by 
setting  interest  levels  according  to  Table  3.2. 

•  AGWCast  -  The  nodes  not  only  use  GWCast,  but  also  use  adaptive  behavior  as 
well.  The  adaptive  behavior  involves  sensing  the  current  network  conditions  and  adjust¬ 
ing  the  infectivity,  also  known  as  the  probability  that  the  node  will  receive  an  update. 

•  SBCast  -  This  is  the  new  protocol  created  as  part  of  this  thesis.  Besides  using 
weights  defined  in  Table  3.2,  and  the  adaptive  behavior  of  AGWCast,  this  protocol  be¬ 
haves  as  outlined  in  the  previous  section:  it  senses  current  network  conditions  and  ad¬ 
justs  the  target  qualities  accordingly. 

The  combinations  of  conditions  and  cases  comprise  the  experiments,  as  outlined 
in  Table  3.3. 
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These  experiments  were  run  ten  times  with  different  random  number  seeds  each 
time.  The  random  number  seeds  are  used  to  seed  the  random  number  generators  from  the 
standard  C/C++  libraries  used  by  the  PBCast  code.  In  addition,  to  simulate  aircraft  loiter¬ 
ing  in  an  area,  all  nodes  will  move  in  simple  orbits  but  not  leave  a  pre-defined  area;  in  the 
ns-2  simulation,  they  will  be  configured  as  normal,  non-mobile  nodes. 

3.6  Objectives 

The  objectives  of  these  experiments  are  to  compare  the  performance  of  the  algo¬ 
rithms  of  the  four  gossip  schemes,  which  include  PBCast,  GWCast,  AGWCast  and 
SBCast,  under  varying  levels  of  waves  of  interference.  The  first  series  of  tests  (Test  Is) 
demonstrate  the  performance  of  traditional  gossip  (PBCast),  the  second  and  third  tests 
(Tests  2  and  3)  test  gravitational  and  adaptive  gravitational  (respectively),  and  the  last  set 
tests  adaptive  gravitational  gossip  (SBCAST)  with  target  adjustment  (Test  4s). 

Performance  is  considered  in  terms  of  how  fast  the  pub-sub  streams  are  sent 
throughout  the  network  and  in  terms  of  how  much  of  the  published  information  is  re¬ 
ceived  by  the  average  subscriber.  In  particular,  the  most  critical  information  must  still  ar¬ 
rive  possibly  at  the  expense  of  less  critical  information  streams.  Less  critical  information 
streams  will  be  proportionately  lowered  when  less  bandwidth  is  available  or  increased  if 
more  bandwidth  is  available.  As  such,  the  experiments  will  measure  key  factors  such  as 
how  well  agents  are  able  to  realize  what  their  available  bandwidth  is,  how  well  they  are 
able  to  change  their  data  stream  subscriptions  to  match  their  predefined  interests,  and 
how  quickly  the  adjustments  can  be  achieved. 
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In  terms  experimental  metrics,  this  is  basically  how  a  protocol  recovers  the 
observed-to-target  ratio.  The  observed-to-target  ratio  is  the  ratio  of  the  observed  infectiv- 
ity  to  the  target  quality.  To  extend  earlier  definitions:  the  observed  infectivity  is  the  actual 
probability  a  *Cast  agent  perceives  in  being  able  to  send  out  an  update  for  a  particular 
group,  and  the  target  quality  is  the  pre-configured  interest  a  group  level  has.  The  ratio  is 
the  ratio  is  basically  an  expression  of  the  observed  probability  a  node  can  send  out  a  mes¬ 
sage  that  will  be  received  by  a  peer,  and  target  quality  is  the  expected  probability  a  node 
can  send  out  a  message  that  will  be  received  by  a  peer.  As  Hopkinson  described  observed 
infectivity[13],  the  observed  infectivity  is  the  result  of  AGWCast’s  weight  algorithm  exe¬ 
cuting  a  least  squares  calculation  on  susceptibility  measurements  taken  at  nodes.  This 
means  that  the  actual  probability  that  a  node  will  send  an  update  is  based  off  of  the  prob¬ 
ability  that  a  node  will  receive  an  update,  which  is  based  off  of  whether  an  agent  has  suc¬ 
cessfully  kept  up  with  gossip  rounds;  the  ratio  of  the  observed  infectivity  indirectly  moni¬ 
tors  the  bandwidth  by  noting  how  successful  a  node  might  be  in  infecting  a  peer  with  an 
update.  The  observed  infectivity,  when  compared  to  the  target  ratio,  should  ideally  be  at 
100%,  indicating  that  the  target  quality  set  for  that  particular  agent  is  utilizing  the  avail¬ 
able  bandwidth  perfectly.  If  the  target  quality  is  less  than  100%,  then  an  agent  is  only  re¬ 
ceiving  a  percentage  of  the  updates  it  expects.  The  lower  the  percentage  value  of  the  ra¬ 
tio,  the  less  efficiently  the  agent  is  using  the  bandwidth  for  sending  and  receiving  updates 
for  a  given  application  group. 

Therefore,  the  observed-to-target  ratio  captures  the  success  of  the  algorithms  in 
the  experiments.  The  higher  the  observed-to-target  ratio,  the  better  the  protocol  adapted 
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Figure  3.8:  Script  Generator  Program 


to  shrinking  or  expanding  bandwidth  as  it  is  receiving  the  majority  of  the  updates  it  ex¬ 
pected  to  receive  in  the  first  place.  The  lower  observed-to-target  ratio,  the  worse  the  pro¬ 
tocol  is  doing  in  terms  of  adapting  to  shrinking  or  expanding  bandwidth.  In  the  former 
case,  the  protocol  is  successfully  “backing  off’  and  preserving  or  reserving  bandwidth  for 
higher  priority  data  streams;  in  the  latter  the  case,  the  protocol  is  unable  to  sense  changes 
in  the  network  and  is  continuing  to  adversely  affect  the  bandwidth  available. 
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These  experiments  will  meet  the  objectives  because  they  demonstrate  the  adapt¬ 
ability  of  the  protocol  under  changing  conditions.  They  will  illustrate  how  SBCast  might 
be  used  as  a  feedback  system  for  higher-level  agents,  and  compare  how  that  feedback 
system  can  provide  improvements  over  traditional  methods  of  non-deterministic  message 
passing. 

3.7  Procedures 

Following  the  Table  3.33  above,  there  are  four  total  tests  to  accomplish,  and  with 
ten  runs  and  three  conditions,  a  total  of  120  runs  to  accomplish.  They  are  automated  us¬ 
ing  a  script  that  builds  the  scenario,  submits  it  to  ns-2,  executes  and  then  records  the  re¬ 
sults  to  a  fde.  Each  test  runs  one  at  a  time,  and  consists  of  initializing  a  topology  with  the 
specific  *Cast  agent  (PBCast,  GWCast,  AGWCast  or  SBCast),  configuring  with  a  spe¬ 
cific  network  traffic  condition,  generating  a  randomly  generated  seed,  and  executing  ns-2 
on  the  newly  created  output.  Another  script  automates  the  interpretation  of  the  collected 
data.  The  entire  process  is  illustrated  in  Figure  3.8. 

To  explain  more  precisely  from  Figure  3.8:  the  script  generator  program  creates  a 
script  for  one  of  the  tests.  It  embeds  a  randomly  generated  number  to  seed  the  random 
generators  in  the  *Cast  agents  to  vary  the  repeated  tests.  Then,  it  executes  that  script  for 
that  test.  When  that  script  is  executed,  it  launches  ns-2  simulator  and  sends  its  informa¬ 
tion  (the  topology  that  is  described  in  the  script)  to  ns-2.  The  simulator  then  executes  the 
scenario  described  by  the  script,  creating  node,  agent  and  application  objects  and  execut¬ 
ing  their  actions.  For  example,  the  *Cast  code  is  a  specialized  agent  object  within  ns-2, 
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and  is  called  and  used  by  the  simulator  as  required  by  the  script.  Hence,  the  script  gen¬ 
erator  creates  different  traffic  conditions,  and  the  ns-2  simulator  utilizes  the  different 
types  of  *Cast  agents.  This  procedure  is  repeated  120  times;  once  for  each  test  required. 

3.8  Summary 

This  chapter  discussed  the  problem  to  be  explored,  the  scenario  to  specify  the 
problem,  described  SBCast,  the  protocol  developed  for  testing,  outlined  the  experiments 
to  test  *Cast  protocols,  and  the  procedures  to  accomplish  the  experiments. 
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IV.  Analysis  and  Results 


4.1  Chapter  Overview 

This  section  reviews  and  evaluates  the  results  of  the  experiments  described  in  the 
previous  chapter.  The  first  part  of  this  chapter  describes  and  displays  the  graphs  of  the 
results.  The  second  part  discusses  their  significance  and  to  the  key  investigative  questions 
posed  at  the  beginning  of  this  paper. 

4.2  Results  of  Simulation 

4. 2. 1  Obsen>ed-to-Target  Graphs 

The  key  question  answered  was  relating  to  how  well  the  protocol  adapted  to  ad¬ 
verse  conditions.  Because  each  scenario  was  run  ten  times  (ten  trials)  with  each  of  the 
three  conditions  (three  experiments),  there  are  three  graphs  for  each  of  the  three  experi¬ 
ments.  Each  graph  records  the  performance  of  all  four  protocols  within  one  experiment  as 
an  x-y  scatter  plot  of  the  observed-to-target  ratio  to  time.  The  adverse  conditions  that  af¬ 
fected  the  protocols  consisted  of  the  traffic  generators  that  were  turned  on,  and  so  each 
graph  also  records  the  number  of  active  CBRs  to  time  as  well. 

Before  the  main  graphs  are  fully  explained,  it  is  important  to  note  the  activity  of 
the  CBRs  and  what  they  are  doing  in  the  main  graph,  because  the  number  of  CBRs  active 
is  the  variable  that  differentiates  the  experiments  from  each  other.  Before  they  are  plotted 
to  the  main  graphs  for  comparison  with  the  observed-to-target  measurements,  it  is  helpful 
to  view  them  on  a  single  graph,  in  Figure  4.1. 
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Figure  4. 1 :  CBR  Counts  For  All  Experiments 


This  graph  has  three  x-y  scatter  plots  per  different  network  conditions.  The  x-axis 
are  in  time  slots  of  100  ms.  The  y-axis  is  the  number  of  CBRs  that  are  turned  on  at  a  time 
slot.  These  graphs  will  be  transposed  directly  onto  the  main  graphs  (see  below). 

Like  the  graphs  in  Figure  4.1,  in  the  main  graphs,  the  x-axis  in  each  graph  repre¬ 
sents  time  in  100  ms  time  slots.  The  y-axis  on  the  left  of  each  graph  is  the  observed-to- 
target  ratio,  and  scales  from  0.00  to  1 .00.  The  y-axis  on  the  right  is  the  number  of  CBRs 
active,  and  is  the  same  y-axis  that  appears  in  Figure  4.1.  The  CBR  graph  specific  to  that 
experiment  appears  in  the  pertinent  graph.  The  values  for  observed-to-target  ratios  are 
geometric  mean  values,  and  these  are  found  using  the  geometric  mean  formula  of: 


Where  n  is  the  total  number  of  agents  in  the  topology,  and  a  is  the  value  of 
observed-to-target  ratio  observed  at  an  agent  during  that  time  slot.  This  mean  was  used 
because  of  the  diversity  of  agents  in  terms  of  locations,  trials  and  interest  levels  set.  The 
graphs  of  the  results  follow  over  the  next  three  pages,  as  Figures  4.2,  4.3  and  4.4. 
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Average  Observed  Infectivity  /  Target  Quality  For  All  Links  Saturated 
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Figure  4.2:  Test  1  Results  (All  Links  Saturated) 
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Figure  4.3:  Test  2  Results  (Narrow  Links  Saturated) 


Average  Observed  Infectivity  /  Target  Quality  For  Wide  Links  Saturated 
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Figure  4.4:  Test  3  Results  (Wide  Links  Saturated) 


4.2.2  Standard  Deviation  Graphs 

The  standard  deviation  graphs  appear  over  the  next  six  pages  as  Figures  4.5  to 
4.16.  Figures  4.5  to  4.8  are  the  standard  deviation  graphs  for  the  first  experiment,  “All 
Finks  Saturated.”  The  second  set  of  four  (Figures  4.9  to  4.13)  are  for  the  experiment 
“Narrow  Links  Saturated”  and  the  third  set  (Figures  4.13  to  4.16)  are  for  the  “Wide 
Links  Saturated”  experiment.  Each  graph  is  similar  to  the  Figures  4.2  to  4.4,  with  the  x- 
axis  as  time  slots  and  the  y-axis  as  the  observed-to-target  ratio,  but  the  CBR  counts  have 
been  omitted.  Each  graph  contains  the  original  x-y  scatter  plot  for  the  observed-to-target 
for  the  specified  protocol,  and  a  bar,  in  the  positive  and  negative  directions,  at  each  data 
point  for  the  standard  deviation  of  the  observed-to-target  ratio  in  the  y-axis.  The  magni¬ 
tude  of  the  bars  is  the  geometric  mean  of  the  standard  deviation  of  the  observed-to-target 
ratio  calculated  at  that  point.  The  standard  deviation  was  calculated  for  the  standard  de¬ 
viation  of  a  sample,  whose  formula  is: 


5  = 


-1 


(n  - 1) 


And  the  resulting  standard  deviation  for  each  node  was  then  put  into  the  geomet¬ 
ric  mean  calculation  stated  in  the  previous  section. 
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Figure  4.5:  SBCast  Standard  Deviation  Graph  for  All  Links  Saturated 
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Figure  4.6:  AGWCast  Standard  Deviation  Graph  for  All  Links  Saturated 
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Figure  4.6:  GWCast  Standard  Deviation  Graph  for  All  Links  Saturated 


Average  Observed  Infectivity  /  Target  Quality  With  Standard  Deviation 


0  500  1000  1500  2000  2500  3000  3500  4000  4500 


Time  (100ms) 

Figure  4.7:  PBCast  Standard  Deviation  for  All  Links  Saturated 
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Figure  4.8:  SBCast  Standard  Deviation  for  Narrow  Links  Saturated 
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Figure  4.9:  AGWCast  Standard  Deviation  for  Narrow  Links  Saturated 
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Figure  4.10:  GWCast  Standard  Deviation  for  Narrow  Links  Saturated 


Average  Observed  Infectivity  /  Target  Quality  With  Standard  Deviation 


0  500 


1000  1500  2000  2500  3000  3500  4000  4500 

Time  (100ms) 


Figure  4.11:  PBCast  Standard  Deviation  for  Narrow  Links  Saturated 
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Figure  4.12:  SBCast  Standard  Deviation  for  Wide  Links  Saturated 
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Figure  4.14:  GWCast  Standard  Deviation  for  Wide  Links  Saturated 
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Figure  4.15:  PBCast  Standard  Deviation  for  Wide  Links  Saturated 


4-12 


4.3  Investigative  Questions  Answered 

The  primary  objective  was  determining  the  applicability  of  SBCast,  an  adaptive 
gravitational  gossip  technique,  to  a  pub-sub  architecture  such  as  a  JBI,  and  whether  or  not 
SBCast  could  maintain  or  improve  the  reliability,  scalability  and  adaptability  of  a  JBI. 
Towards  this  objective,  the  key  investigative  questions  was  how  well  SBCast  perform  in 
a  JBI,  given  a  battlefield  scenario.  How  would  SBCast  manage  the  bandwidth  by  control¬ 
ling  or  restricting  updates?  These  results  demonstrate  how  SBCast  would  perform,  re¬ 
garding  its  ability  to  recapture  an  observed-to-target  ratio  of  100%,  and  dealing  with  in¬ 
creased  bandwidth  in  this  experiment 

The  primary  objective  of  these  experiments  was  to  determine  the  applicability  of 
SBCast  to  JBIs,  and  whether  or  not  SBCast  could  maintain  or  improve  the  reliability, 
scalability  and  adaptability  of  a  JBI.  Towards  this  objective,  the  experiments  simulated  a 
battlefield  scenario  that  applied  JBI  and  also  modeled  background  traffic.  The  results  are 
in.  Given  this  problem  domain,  how  would  SBCast  manage  the  bandwidth  by  controlling 
or  restricting  updates?  Or,  more  specifically,  from  Chapter  I,  the  key  investigative  ques¬ 
tions  to  answer  are: 

•  Can  SBCast  be  applied  to  an  operational  JBI  scenario? 

•  How  would  SBCast  perform  as  a  controller  component  in  JBI  middle¬ 
ware,  specifically  in  regards  to  scalability,  reliability  and  adaptability? 
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This  section  answers  each  question  individually,  based  on  the  graphed  results. 
Each  question  is  given  its  own  subsection.  The  second  question  actually  contains  three 
questions,  so  each  sub-question  is  regarded  separately. 

4.3.1  Can  SBCast  be  applied  to  an  operational  JBI  scenario? 

Yes,  SBCast  is  applicable  to  an  operational  JBI.  In  transforming  the  original  *Cast 
experiments  so  that  they  fit  a  scenario  that  modeled  a  battlefield  in  which  a  JBI  would  be 
employed,  the  system  of  gravitational  weights  and  target  qualities  was  shown  to  work 
well  with  the  stated  requirements  of  JBIs.  From  the  main  graphs  (Figures  4.2,  4.3  and 
4.4)  one  can  tell  from  the  maintenance  of  the  observed-to-target  ratio  that  any  of  the 
*Cast  protocols  can  act  as  a  controller  can  assure  some  expected  rate  of  updates.  At  first, 
when  there  is  no  traffic  from  either  the  CBRs  or  the  agents,  the  observed-to-target  ratio  is 
100%,  but  when  traffic  from  both  the  CBRs  and  the  agents  start,  each  protocol  drops  to 
around  some  percentage  of  the  observed-to-target  ratio.  For  PBCast,  its  x-y  plot  resided 
around  20%;  for  AGWCast  and  GWCast  this  was  around  45%.  SBCast,  however,  sets 
itself  apart  from  the  others  because  its  slacking  technique  recovers  some  of  the  observed- 
to-target  ratio,  from  45%  to  65% 

This  specific  requirement  that  this  question  is  addressing  is  the  ability  of  SBCast 
to  handle  differing  priorities  of  different  subscribers.  In  generating  the  results  for  Figures 
4. 2, 4. 3  and  4.4,  the  standard  deviations  for  SBCast,  AGWCast  and  GWCast  varied  10- 
15%  around  the  geometric  mean,  whereas  PBCast  had  near  0%,  as  shown  in  their  respec¬ 
tive  standard  deviation  graphs  (Figures  4.5-4.16).  This  variety  of  readings  for  SBCast, 
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GWCast  and  AGWcast  shows  that  the  observed  infectivity  varied  from  node  to  node, 
meaning  that  nodes  in  those  protocols’  trials  viewed  varied  levels  of  infectivity  and  thus 
had  different  levels  of  bandwidth  for  different  groups  it  could  receive  updates  for.  This 
implies  that  there  was  control  over  the  quality  of  updates  different  nodes  received  from 
different  groups.  The  opposite  case  would  be  that  the  standard  deviation  for  the 
observed-to-target  ratio  at  each  node  would  be  around  0%,  as  all  agents  in  that  network 
would  send  or  receive  around  the  same  amount  of  messages.  The  only  trials  that  have  that 
standard  deviation  are  the  PBCast  trials,  and  the  PBCast  trials  are  the  only  trials  that  do 
not  use  interest  levels  as  well.  More  conclusive  evidence  would  be  to  graph  the  observed- 
to-target  ratios  at  each  node,  but  for  the  purposes  of  this  paper  these  geometric  mean  val¬ 
ues  for  observed-to-target  ratio  with  large  standard  deviations  indicate  that  SBCast, 
GWCast  and  AGWCast  are  modifying  bandwidth  availability  according  to  the  interest 
levels  set. 

Again,  what  sets  SBCast  apart  from  GWCast  and  AGWCast  is  that  it  recovers 
some  of  the  observed-to-target  ratio.  But  what  is  interesting  with  the  case  of  SBCast  is 
even  as  it  adjusts  the  target  qualities,  it  maintains  nearly  the  same  standard  deviation 
range  as  AGWCast  and  GWCast  as  it  increases  the  observed-to-target  ratio.  Inspecting 
graph  4.5,  4.9  and  4.13,  one  can  see  that  SBCast  appears  to  behave  similarly  to  GWCast 
and  AGWCast  for  the  first  forty  time  slots,  or  four  seconds.  This  corresponds  to  the  first 
ten  adaptive  rounds  that  SBCast  must  wait  before  it  starts  adjusting  targets.  An  adaptive 
round  is  when  the  adaptive  mechanisms  in  AGWCast  and  GWCast  adjust  the  gravita¬ 
tional  weights,  which  occur  every  400  ms,  or  four  time  slots  [13].  This  relates  to  the  call 
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to  SBCast’s  target  adjustment  algorithm,  which,  as  remarked  by  the  pseudo-code  from 
Figure  3.6,  is  placed  right  before  AGWCasf  s  weight  adjustment.  Once  the  SBCast  target 
adjustment  strategy  is  able  to  start,  then  the  observed-to-target  values  begin  to  grow  back 
towards  100%.  During  that  growth,  the  standard  deviation  varies  by  roughly  the  same 
range  as  AGWCast  and  GWCast,  10-15%.  This  indicates  that  the  ability  to  prioritize 
streams  is  maintained  even  as  target  qualities  are  modified.  Therefore,  SBCast  fits  the 
requirement  for  applicability  to  the  JBI,  and  that  it  successfully  manages  different  priori¬ 
ties  of  subscribers  to  specified  application  streams. 

Unfortunately,  the  graph  of  SBCast  in  any  of  the  scenarios  did  not  recover  the 
observed-to-target  ratio  back  or  close  to  100%.  This  means  that  SBCast  is  not  yet  at  ideal 
for  JBI  usage.  The  objective  of  this  question  is  whether  SBCast  can  be  applied  as  a  con¬ 
troller  to  JBI;  the  next  question  deals  with  to  what  degree  SBCast  is  useful  at  this  point  in 
its  development,  and  will  also  address  the  issue  of  why  SBCast  does  not  recover  to  the 
100%  of  the  desired  observed-to-infect  ratio. 

4.3.2  How  would  SBCast  perform  as  a  middleware  controller  in  JBIs? 

The  answer  to  this  investigative  question  is  broken  into  three  sections,  corre¬ 
sponding  to  the  evaluation  of  SBCast  in  regards  to  scalability,  reliability  and  adaptability. 
Although  each  section  evaluates  the  graphs  separately,  there  is  one  factor  in  the  results 
that  prevents  reliability  and  adaptability  from  being  accurately  assessed,  and  that  factor  is 
the  effect  of  the  CBRs. 
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After  evaluating  the  results  data  and  generating  the  scatter  plots  graphs  that  would 
become  Figures  4.2  to  4.16,  it  was  discovered  that  the  CBRs  appeared  to  have  no  effect. 
The  example  expected  behavior  for  a  gossip  protocol  is  portrayed  in  the  hypothetical 
graph  in  Figure  4.17:  as  more  CBRs  were  turned  on,  each  of  the  gossip  protocols  would 


Expected  Behavior  of  Gossip  Protocol  In  Response  To  Traffic 


CBR  Count 


Figure  4. 17:  An  Example  of  Expected  Behavior  In  Response  To  Traffic 
“bow”  or  “morph”  at  first,  but  then  would  adjust  back.  However,  in  examining  all  three 
collected  graphs  (Figures  4. 2-4. 4)  it  was  discovered  that  the  observed-to-target  ratios 
were  all  the  same  for  all  protocols,  and  did  not  vary  in  response  to  more  or  less  CBRs  be¬ 
ing  turned  on  by  the  scenario  script  as  the  time  slots  increased.  After  re-examining  the 
configuration  scripts  for  the  experiments,  calculations  were  made  considering  the  sce¬ 
nario  link’s  capacity  values  and  the  configuration  of  the  CBRs.  This  estimation  of  the 
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size  of  the  background  verified  that  the  CBRs  would  have  little  effect  when  compared  to 
the  *Cast  traffic.  A  fix  would  be  to  re-run  the  tests  using  CBRs  that  would  output  more 
intense  levels  of  traffic.  Due  to  time  constraints  re-testing  will  be  addressed  in  future 
work. 

One  uncertainty  that  this  development  brings  is  the  comparison  between  the 
GWCast  and  AGWCast  graphs.  AGWCast  differs  from  GWCast  in  the  employment  of 
the  adaptive  mechanism,  geared  towards  adjusting  the  gravitational  weights  in  response 
to  background  traffic.  Without  the  CBRs  producing  significant  background  traffic,  there 
would  be  no  visible  difference  between  the  observed-to-target  ratio  graphs  for  either 
GWCast  and  AGWCast,  because  the  adaptive  mechanism  might  not  be  reacting  properly 
in  AGWCast.  Most  likely,  with  the  adaptive  mechanism,  AGWCast  (and  ultimately 
SBCast,  which  inherits  the  adaptive  mechanism  as  well)  would  show  a  graph  that  is  more 
aggressively  reacting  to  the  cumulative  traffic  than  the  one  that  appears  in  the  Figure 
4.17. 

As  a  result,  reliability  and  adaptability  cannot  be  accurately  assessed  at  this  time, 
although  the  answer  to  the  question  could  be  reasonably  investigated,  as  well  as  scalabil¬ 
ity.  Both  can  be  interpreted  without  consideration  for  background  traffic.  Each  section, 
then,  will  interpret  the  results  separately,  and  also  in  regards  to  the  absence  of  the  CBRs. 

4.3.3  Scalability 

The  observed-to-target  ratio  can  be  considered  a  direct  measure  of  scalability.  Al¬ 
though  traditional  probabilistic  techniques  have  been  proven  to  be  scalable  [4],  they  have 
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a  reputation  for  being  “noisy”.  This  noisiness  means  that  the  more  gossip  agents  we  place 
in  a  graph,  the  “noisier”  it  will  be  and  so  there  is  a  problem  with  scale.  This  problem  with 
scale  is  not  directly  tied  to  the  number  of  nodes  or  agents,  but  rather  a  problem  of  the 
number  of  nodes  or  agents  in  the  network  medium  chosen;  one  such  example  is  using 
gossip  in  a  WAN  environment  as  tested  by  Rodriguez  with  NEEM  [21].  With  the  *Cast 
family,  to  some  degree  this  can  be  demonstrated  with  Figures  4. 2-4.4.  The  observed-to- 
target  ratio  hovers  at  a  certain  level  and,  with  some  variance,  maintains  roughly  that  level. 
PBCast  remains  at  around  20%,  GWCast  and  AGWCast  maintain  roughly  45%,  while 
SBCast  rises  from  40%  to  65%.  Ideally,  this  should  be  100%.  However,  if  none  of  these 
protocols  was  scalable,  one  would  observe,  over  time  goes  by,  that  the  observed-to-target 
ratio  would  deteriorate  as  agents  would  send  more  and  more  updates.  These  updates 
would  accumulate  over  time,  and  the  results  would  be  a  lower  observed-to-target  ratio  as 
a  network  becomes  clogged  with  messages  and  the  observed  infectivity  goes  down. 
However,  as  seen  in  Figures  4. 2-4. 4,  this  is  not  the  case  and  the  plots  of  PBCast,  GWCast 
and  AGWCast  maintain  roughly  the  aforementioned  observed-to-target  ratios.  Although 
a  more  direct  test  would  be  to  successively  increase  the  number  of  agents,  this  actually 
demonstrates  an  attribute  of  *Cast  agents:  that  through  a  timeout  setting  for  a  message,  an 
update  is  considered  too  old  to  accept  and  would  be  dropped  [3].  In  the  gravitational 
gossip  protocols,  this  becomes  a  factor  in  the  susceptibility  of  an  agent  with  respect  to  a 
specific  message,  and  thus  a  factor  in  the  weight  calculation. 

That  distinction  results  in  an  observation:  that  gravitational  *Cast  are  more  scal¬ 
able  than  PBCast,  a  traditional  gossip  protocol.  The  evidence  of  this  is  in  the  observed-to- 
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target  ratio  for  the  gravitational  protocols  versus  the  non-gravitational  protocols:  the 
observed-to-target  ratios  are  much  higher.  The  higher  the  ratio,  the  higher  percentage  of 
the  messages  agents  are  able  to  send  out.  This  shows  that,  even  with  the  same  number  of 
agents,  the  agents’  updates  are  not  interfering  as  much  with  each  other  in  the  three  gravi¬ 
tational  trials  as  the  non-gravitational.  Because  SBCast  shares  the  gravitational  character¬ 
istics  of  GWCast  and  AGWCast,  SBCast  can  add  scalability  qualities  to  JBIs. 

4.3.4  Reliability 

A  perfect  observed-to-target  ratio  of  100%  means  that  all  messages  that  are  sent 
are  also  received.  However,  for  each  of  the  *Cast  protocols  none  have  achieved  that  per¬ 
fect  100%,  or  close  to  it.  In  the  case  of  PBCast,  only  20%  of  messages  were  received  in 
all  experiments;  in  AGWCast  and  GWCast,  only  45%  of  messages  were  received.  For 
SBCast,  the  protocol  recovered  from  45%  of  messages  received  to  65%  of  messages  re¬ 
ceived.  An  obvious  interpretation  is  this:  because  none  of  the  *Cast  protocols,  including 
SBCast,  can  keep  a  perfect  or  near-perfect  observed-to-target  ratio,  then  SBCast  cannot 
provide  reliability.  On  the  other  hand,  does  a  perfectly  100%  reliable  protocol  exist?  If 
one  did  exist,  then  protocol  research  would  never  be  required  again.  In  light  of  the 
observed-to-target  ratios  interpreted  from  Figures  4. 2-4. 4,  it  could  be  said  that  in  general 
PBCast  is  not  as  reliable  as  AGWCast  or  GWCast,  and  GWCast  or  AGWCast  is  not  as 
reliable  as  SBCast.  Likewise,  as  SBCast  recovers  the  observed-to-target  ratio,  then 
SBCast  is  not  at  first  reliable,  but  may  recover  to  nearly  100%  reliability  over  time. 
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But  even  this  explanation  does  not  satisfy  the  absence  of  CBRs,  or  answer  the 
question  as  to  why  SBCast  does  not  fully  recover  the  observed-to-target  ratio  to  achieve 
reliability.  One  requirement  for  reliability  for  JBIs  would  be  that  the  protocol  reacts  to 
background  traffic  and  recovers  completely.  Since  the  CBRs  did  not  have  a  significant 
impact,  then  the  graph  for  SBCast  recovers  gradually  but  not  completely,  without  reacting 
to  any  background  traffic.  This  indicates  that  SBCast  does  not  fully  recover  from  traffic  it 
creates,  and  would  most  likely  not  recover  from  background  traffic.  This  also  indicates 
that  even  without  additional  interference,  SBCast  does  not  reach  the  ideal  100%  needed 
to  improve  reliability  in  JBIs. 

By  contrast,  the  other  *Cast  protocols  do  not  recover  any  of  the  observed-to-target 
ratio.  Because  the  other  *Cast  protocols  do  not  have  a  target  adjustment  strategy,  the 
observed-to-target  ratio  is  static  throughout  the  entire  scenario  and  would  never  improve. 
Therefore,  the  fact  that  SBCast  partially  recovers  is  an  improvement  upon  its  relatives. 
This  minor  improvement  leads  to  an  explanation  as  to  why  the  observed-to-target  ratio  of 
SBCast  did  not  improve  fast  enough:  it  is  not  aggressive  enough  in  adjusting  the  target. 

Referring  to  the  pseudo-code  for  the  historical  target  strategy  in  Figure  3.7,  there 
are  several  possible  factors  that  contribute  to  SBCast’s  conservative  behavior.  The  first  is 
the  length  of  the  history  buffer,  which  is  ten  adaptive  rounds  long.  If  a  time  slot  is  100 
ms,  an  adaptive  round  takes  4  slots,  and  the  historical  strategy  waits  ten  adaptive  rounds, 
then  the  historical  target  strategy  is  initially  waiting  40  seconds  before  it  can  begin  to  re¬ 
act  to  network  activity.  Additionally,  because  of  the  historical  strategy’s  length,  the  net¬ 
work  conditions  could  actually  be  improving  but  not  meet  the  algorithms  thresholds.  The 
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thresholds  of  the  historical  strategy  are  that:  1)  it  looks  for  eight  of  ten  rounds  of  higher 
observed  infectivity  readings  and  2)  it  looks  for  at  least  five  rounds  of  decreasing  suscep¬ 
tibility.  By  the  time  the  algorithm  is  able  to  react  to  what  it  perceives  to  be  improving 
conditions,  the  conditions  could  become  worse,  and  conversely  by  the  time  the  strategy 
reacts  to  worsening  conditions,  conditions  might  actually  improve. 

Another  possible  conservative  factor  is  the  improvements  made  to  the  quality  tar¬ 
get.  In  one  rare  case,  the  target  quality  is  restored  to  its  original  value  only  if  the  suscepti¬ 
bility  is  close  to  0,  a  highly  unlikely  event.  A  susceptibility  of  0  means  that  all  agents 
have  received  all  their  updates,  a  nearly  impossible  occurrence.  This  is  the  most  aggres¬ 
sive  restoration  of  the  target  quality,  where  the  other  increments  added  to  the  target  qual¬ 
ity  are  mere  fractions  of  the  difference  between  the  original  target  and  the  current  target. 
With  the  less  aggressive  improvements  to  restore  the  target  quality,  the  target  quality  im¬ 
proves  too  slowly,  and  results  in  affecting  the  gravitational  weights  gradually,  which  in 
turn  might  prevent  network  conditions  from  improving. 

The  last  possible  factor  to  discuss  is  the  value  by  which  the  target  quality  is  re¬ 
duced.  The  historical  target  locates  the  best  observed  infectivity  in  the  history  buffer  and 
sets  it  as  the  new  target  quality.  If  this  max  value  is  actually  an  outlier  and  not  close  to  the 
average  across  the  recorded  observed  infectivities,  this  could  result  in  the  target  quality 
remaining  still  too  high  for  the  agent  to  keep  up  with.  As  a  result,  SBCast  will  continue  to 
fail  in  meeting  the  target.  This  could  continue  and  SBCast  would  re-adjust  the  target  qual¬ 
ity  with  the  best  observed  infectivity.  The  common  case  would  be  that  the  value  of  the 
best  infectivity  would  also  drop  severely,  but  it  is  still  possible  that  another  outlier  with 
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the  same  or  similar  value.  This  would  result  in  SBCast  lowering  the  target  qualities 
slightly  and  perpetually  missing  them. 

At  this  point,  the  results  do  not  demonstrate  whether  or  not  SBCast  would  make 
JBIs  more  reliable.  However,  what  can  be  inferred  is  that  the  target  adjustment  strategy  of 
SBCast  must  be  improved  to  deal  with  background  traffic  and  traffic  from  its  own  agents, 
so  as  to  move  closer  to  the  ideal  100%  object-to-target  ratio  that  would  benefit  JBIs. 

4.3.5  Adaptability 

Adaptability  is  related  to  reliability,  and  deals  with  the  protocol’s  ability  to  main¬ 
tain  an  expected  level  of  updates  despite  bandwidth  changes.  As  noted  previously,  the 
CBRs  did  not  appear  to  make  a  significant  impact  on  the  network.  As  a  result,  neither  can 
adaptability  be  verified  with  other  traffic.  However,  from  the  observed-to-target  ratio 
graphs  (Figures  4.2-4.4),  it  is  evident  that  the  *Cast  protocol  traffic  affects  itself,  which  is 
why  the  observed-to-target  ratios  are  never  fully  100%.  Some  of  the  possible  behavior 
with  additional  traffic  generators  could  be  inferred,  and  with  SBCast’s  improvement  of 
the  observed-to-target  ratio,  SBCast  is  adapting. 

If  any  of  the  *Cast  protocols  truly  were  adapting,  what  would  the  graph  look  like? 
As  mentioned  previously,  the  expected  behavior  (Figure  4.17)  characterizes  this  possible 
form.  To  reiterate:  the  graph  should  at  first  be  affected  when  CBR  activity  builds,  but 
then  the  graph  should  recover  to  either  its  original  observed-to-target  ratio  or  towards 
100%.  If  SBCast  were  adapting,  its  graph  would  dip  momentarily  in  response  to  the 
buildup  of  traffic,  and  then  re-adjust  back  to  its  original  value.  There  is  no  apparent  CBR 
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activity  in  the  graphs  SBCast  in  Figures  4.2-4A,  but  from  any  of  those  three  graphs 
SBCast  starts  out  at  100%,  then  drops  immediately  when  its  own  agents  start  to  send  up¬ 
dates.  Despite  the  interference  caused  by  its  own  updates,  the  target  strategy  activates  and 
begins  to  raise  the  observed-to-target  ratio  closer  to  100%.  This  behavior  correlates  to  the 
expected  behavior  for  a  gossip  protocol  in  adapting  to  background  traffic:  that  the  traffic 
would  occur,  but  the  protocol  should  adjust  in  response.  However,  actually  having  sig¬ 
nificant  test  traffic  would  verify  this.  Therefore,  even  with  this  self-inflicted  traffic, 
SBCast  still  recovers  closer  towards  100%,  indicating  that  SBCast  is  indeed  reacting  to 
traffic  and  adapting. 

4,4  Summary 

This  chapter  displayed  the  results  of  running  the  various  experiments  outlined  in 
chapter  three  and  interpreted  their  direct  meaning  to  the  investigative  questions  posed  in 
Chapter  I.  Although  the  complete  recovery  of  the  observed-to-target  ratio  was  not 
achieved  within  the  duration  of  the  scenario,  the  technique  of  “slacking”,  or  dialing  up  or 
down  the  target  qualities,  does  show  some  potential  for  lowering  the  rate  of  updates  for 
lesser  priority  data  streams  and  preserving  bandwidth  available  overall. 
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V.  Conclusions  and  Recommendations 


5.1  Chapter  Overview 

This  chapter  covers  the  conclusions  that  arose  from  the  experiments  and  the 
analysis  of  those  experiments,  recommendations  for  actions  and  recommendations  for 
future  research.  The  conclusions  discusses  the  direct  results  and  what  these  entail  for  em¬ 
ploying  SBCast  or  *Cast  to  JBI  implementations.  Recommendations  for  action  discusses 
some  of  the  issues  during  experimentation  and  development  and  how  these  could  be 
remedied.  In  essences,  Recommendations  for  Action  explains  how  these  experiments 
could  be  better  re-accomplished  in  the  near  term.  Recommendations  for  Future  Research 
discusses  possible  avenues  for  extending  this  work,  to  include  possibly  implementing  a 
prototype  version  of  *Cast  for  inclusion  in  the  current  JBI  suite. 

5.2  Conclusions  of  Research 

Regarding  the  resulting  graphs,  certain  overall  conclusions  can  be  drawn  regard¬ 
ing  SBCast  and  any  of  the  *Cast’s  inclusion  in  the  JBI.  These  include  the  expected  qual¬ 
ity  of  updates,  dealing  with  the  expected  quality  of  updates,  and  its  implementation. 

A  strictly  probabilistic  approach  agrees  with  prior  research.  The  results  demon¬ 
strate  Rodriguez  conclusion,  that  gossip  protocols  like  PBCast  tend  to  be  “noisy”  and  are 
inefficient  users  of  bandwidth  [21].  The  graph  for  PBCast  in  all  three  experiments  (Fig¬ 
ures  4.2,  4.3  and  4.4)  demonstrates  this  fact.  In  all  three  cases,  bandwidth  utilization  in¬ 
ferred  by  the  observed-to-target  ratio  was  below  20%.  That  is,  PBCast  agents  were  re¬ 
ceiving  less  than  twenty  percent  of  their  expected  messages.  Since  this  is  both  the  base- 
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line  for  the  *Cast  family,  there  is  room  for  improvement,  the  improvements  made  to 
PBCast’s  successors,  GWCast  [3]  and  AGWCast  [13]  from  Hopkinson’  research  certainly 
enhance  the  observed-to-target  ratio. 

Expected  quality  of  updates.  It  is  apparent  from  these  graphs  that  transmissions 
from  *Cast  nodes  overall  maintain  the  same  consistency  for  the  entire  period.  Although 
some  traffic  was  introduced,  the  overall  geometric  means  remained  at  the  same  level  for 
PBCast,  GWCast  and  AGWCast.  The  effects  of  the  traffic  generators  were  actually  more 
noticeable  (if  at  all)  towards  the  second  half  of  the  scenario,  when  all  CBRs  were  active 
and  began  to  drop  off.  The  standard  deviations  across  levels  varied  more,  although  not 
noticeably.  However,  overall  the  observed-to-target  ratios  are  less  than  50%.  Signifying 
that  half  the  expected  messages  are  not  received,  this  fact  still  highlights  the  need  for  a 
technique  for  raising/lowering  target  quality  to  raise  the  observed-to-target  ratio  and  thus 
use  available  bandwidth  more  easily. 

The  SBCast  technique  of  backing  off  target  qualities  and  then  recovering  shows 
promise.  Although  more  work  could  be  accomplished  towards  both  providing  more  chal¬ 
lenging  traffic  or  extending  the  length  of  the  experiments,  the  SBCast  graph  shows  the 
protocol  beginning  to  recover  towards  the  perfect  100%  observed-to-target  ratio.  If  given 
more  time,  then  perhaps  SBCast  could  have  restored  to  over  90%,  as  the  graph  shows  a 
gradual  recovery.  As  discussed  in  the  previous  chapter,  the  target  strategy  used  by  SBCast 
in  the  experiments  is  not  aggressive  enough  in  adjusting  the  target  qualities. 

Applicability  to  Joint  Battlespace  Infosphere.  From  the  perspective  of  these  ex¬ 
periments,  a  scenario  that  involved  or  resembled  units  involved  in  a  military  operation 
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successfully  used  SBCast  agents  to  send  and  receive  updates.  The  scenario  yielded  results 
that  showed  that  SBCast  agents  (or  any  *Cast  agent)  can  maintain  some  expected  level  of 
quality  of  transmissions.  With  SBCast,  there  is  a  mechanism  in  place  that  can  “back  off’ 
under  conditions  where  bandwidth  may  not  be  available.  This  ability  to  give  “slack”  to 
the  target  qualities  could  allow  a  probabilistic  protocol  to  function  in  an  intermittent  envi¬ 
ronment,  such  as  wireless  links.  As  a  result,  *Cast  protocols  can  be  applied  as  a  middle¬ 
ware  layer  for  JBIs. 

5.3  Recommendations  for  Action 

Like  most  research,  there  areas  that  were  either  not  explored  or  areas  that  were 
not  explored  fully.  These  directions  might  lead  to  better  insight  into  using  SBCast  or  de¬ 
riving  another  *Cast  variant  in  making  JBIs  more  scalable  and  reliable.  These  include 
upgrading  the  realism  of  the  simulated  traffic  generated  within  the  scenarios,  improving 
the  target  adjustment  strategy  and  re-engineering  the  *Cast  family  for  better  maintainabil¬ 
ity  and  performance. 

Upgrading  the  realism  of  the  traffic  in  the  scenario.  Although  great  pains  were 
taken  in  bending  and  grafting  the  scenarios  to  reflect  more  closely  a  possibly  real-world 
JBI  implementation,  there  was  one  specific  deficiency.  The  traffic  was  modeled  as  a  se¬ 
ries  of  constant  bitrate  generators  to  abstract  the  randomness  of  traffic,  but  the  expected 
levels  of  traffic  were  not  achieved.  Currently,  the  CBRs  introduced  some  traffic,  but  was 
not  enough  to  make  a  dramatic  effect.  Additionally,  rather  than  following  a  single,  rolling 
wave  approach  that  yields  a  steady  rise  and  fall  of  the  traffic,  a  single  rise  during  the  first 
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third  of  the  traffic  and  then  a  constant  and  consistent  level  of  traffic  for  longer  periods 
might  also  induce  more  positive  reactions  form  SBCast.  Basically,  making  it  larger  and 
constant,  instead  of  the  rolling  approach  taken  by  these  experiments,  could  enhance  the 
realism  of  the  traffic. 

Multiple  senders.  This  experiment  and  previous  *Cast  experiments  all  utilize  one 
sender,  which  is  unrealistic  in  real  world  operational  use.  The  use  of  the  JBI  would  con¬ 
sist  of  different  units  being  able  to  push  updates  via  pub-sub  to  all  subscribers.  Senders 
introducing  updates  produces  affects  on  the  traffic  that  should  be  accounted  for.  To  better 
model  this,  multiple  senders  should  exist  in  a  scenario  to  make  the  experiment  more  real¬ 
istic  to  possible  use.  The  decision  to  continue  with  one  sender  was  based  on  performance 
issues;  per  some  of  the  limitations  noted  in  the  point  for  improving  performance,  having 
more  than  one  sender  multiplied  the  runtime  of  an  experiment  by  the  number  of  senders. 
Therefore,  this  recommendation  is  to  increase  performance  to  support  the  use  of  multiple 
senders. 

Improving  the  target  adjustment  strategy.  Currently,  SBCast’s  adjustment  strategy 
is  not  very  aggressive  in  recovering.  Specifically,  it  only  adjusts  the  target  quality  back 
gradually.  As  mentioned  in  the  conclusions  section,  given  more  time  the  protocol  could 
have  recovered  the  observed-to-target  ratio  significantly.  A  good  future  experiment  would 
be  to  modify  the  target  adjustment  strategy  to  more  or  less  aggressiveness,  and  then 
measure  the  effects.  A  comparison  of  how  quickly  the  protocol  recovers  would  demon¬ 
strate  the  strengths  of  an  aggressive  or  gradual  approach  for  SBCast  to  adjust  the  target 
qualities.  In  fact,  the  historical  target  adjustment  strategy  could  be  easily  replaced  with  a 
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more  aggressive  strategy,  due  to  Liskov’s  substitution  principle  [17]  and  the  utilization  of 
the  strategy  design  pattern[12]  in  implementing  SBCast.  One  feasible  path  of  research 
would  be  to  create  a  whole  series  of  target  adjustment  strategies,  and  compare  their  per¬ 
formance  to  each  other. 

Re-engineering  *Cast  protocols  for  maintainability  and  speed  performance.  This 
covers  quick  modifications  that  can  be  accomplished  in  relatively  short  time.  An  example 
of  a  software  engineering  enhancement  would  be  similar  to  the  use  of  a  strategy  design 
pattern  as  described  in  the  implementation  of  SBCast’s  target  quality  adjustment  routine, 
except  applied  to  another  part  of  the  *Cast  base  code.  One  likely  candidate  would  be  the 
adaptive  mechanism.  This  would  allow  opportunities  to  explore  enhancements  to  the 
gravitational  gossip  mechanism. 

An  example  of  a  performance  enhancement  would  be  the  use  of  calls  to  MatLab’s 
libraries  for  lsqcurvefit  routines.  Currently,  the  implementation  of  the  adaptive 
mechanism  relies  on  having  an  instance  of  Matlab  running.  Having  a  separate  instance  of 
Matlab  in  order  to  execute  the  lsqcurvefit  routines  slows  down  the  overall  runtime 
of  the  simulations,  because  processing  must  be  diverted  to  Matlab.  The  method  of  proc¬ 
ess  communication  with  the  Matlab  instance  is  time  intensive.  By  implementing  a  direct 
library  call,  the  execution  of  the  *Cast  protocol  would  bypass  the  overhead  produced  by 
running  and  communicating  with  a  separate  instance  of  Matlab.  Tests  could  be  run  within 
hours,  instead  of  days. 

By  implementing  the  smaller  software  engineering  enhancements,  the  *Cast 
source  code  would  both  have  a  smaller  learning  curve,  be  easier  to  translate  for  use  in 
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JBIs  and  simpler  to  maintain  or  modify.  By  implementing  the  performance  enhancement, 
experiments  utilizing  *Cast  code  could  be  executed  more  quickly  and  yield  more  imme¬ 
diate  results,  so  that  the  algorithms  could  be  evaluated  faster. 

5,4  Recommendations  for  Future  Research 

Recommendations  for  future  work  follow  in  similar  vein  for  recommendations 
for  action.  These  focus  on  re-engineering  *Cast  code  for  better  maintainability  and  im¬ 
proving  performance.  However,  the  difference  is  that  the  future  research  could  yield 
*Cast  variants  that  might  better  perform  in  JBIs  and  also  would  be  more  straightforward 
and  applicable  to  real  implementation. 

Modularize  *Cast.  One  specific  software  engineering  issue  with  the  *Cast  code  is 
that  it  does  not  cleanly  delineate  methods  or  functionalities  with  each  other.  If  the  various 
components  and  modules  were  more  apparent,  modifying  them  would  be  more  straight¬ 
forward.  The  use  of  design  patterns,  such  as  the  strategy  pattern  used  to  implement  the 
target  adjustment  strategy  for  SBCast,  would  help  in  delineating  the  different  methods 
from  each  other,  or  perhaps  moving  the  methods  to  the  best  locations  within  classes  for 
higher  cohesion  and  lower  coupling.  Higher  cohesion  and  lower  coupling  are  two  of  nine 
General  Responsibility  Assignment  Software  Patterns,  defined  by  Larman,  a  software  en¬ 
gineering  researcher  [16],  Higher  cohesion  means  that  methods  of  modules  have  tight, 
focused  functionality  and  lower  coupling  means  that  there  is  less  dependence  on  modules 
having  to  know  internals  of  each  other  to  accomplish  their  functions.  Once  modularized, 
the  components  can  be  adjusted  and  tested  for  maximum  effect  (as  measured  in  the  ex- 
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periments  in  the  future)  and  also  can  be  translated  directly  into  a  real  world  implementa¬ 


tion  of  a  JBI. 

Distribution  of  ^Cast’s  data  structure.  Currently,  the  coordination  among  *Cast 
agents  takes  place  within  a  large,  multidimensional  C/C++  arrays.  This  design  decision 
speeds  up  the  ns-2  simulation  and  abstracts  away  the  coordination  overhead  a  distributed 
systems  protocol  might  produce,  but  also  creates  an  inflexible  agent  that  is  difficult  to 
execute  or  describe  for  ns-2.  One  glaring  limitation  of  the  use  of  this  data  structure  is  that 
varying  numbers  of  senders  and  groups  are  not  implementable;  since  the  multidimen¬ 
sional  array  is  required  to  have  an  element,  some  groups  or  senders  cannot  be  omitted, 
limiting  certain  topology  configurations.  By  modifying  the  underlying  data  structure, 
greater  flexibility  in  creating  scenarios  could  be  achieved,  resulting  in  scenarios  of 
greater  scale,  variety  and  realism. 

Real  implementation  of  SBCast.  To  fully  answer  the  investigative  question  as  to 
how  well  SBCast  (or  any  *Cast)  agent  would  work  in  practice  would  be  to  construct  a 
prototype.  This  prototype  could  also  be  matched  to  prototypes  of  IESTs  to  work  out  how 
the  components  would  inter-operate.  This  could  be  done  by  using  (hopefully  modular¬ 
ized)  *Cast  source  code  and  translating  from  the  ns-2  model  into  an  actual  language. 


5.5  Summary 

This  paper  explored  the  use  of  probabilistic  protocols  in  JBI.  In  particular,  it  ex¬ 
plored  the  need  for  scalability/reliability,  and  utilized  a  novel  technique  for  adjusting  the 
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target  qualities  (the  expected  rate  of  updates).  Adding  this  technique  to  the  *Cast  family 
of  probabilistic  protocols,  this  protocol,  dubbed  SBCast,  was  tested  over  three  experi¬ 
ments  with  varying  network  conditions.  The  results  showed  that  probabilistic  protocols 
could  apply  to  providing  middleware  services  for  monitoring  the  Joint  Battlespace 
Info  sphere. 
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Appendix  A:  Development  of  Ruby  Cast:  The  *Cast  Script  Generator 


A.l  Appendix  Overview 

One  significant  problem  that  was  not  directly  tied  to  the  investigative  questions 
but  was  instrumental  in  completing  this  thesis  was  bringing  the  original  *Cast  experi¬ 
ments  from  the  academic  environment  into  a  military  operational  scenario.  Initially,  the 
estimates  for  the  time  needed  to  develop  a  workable  scenario  were  optimistically  brief. 
Hopkinson,  Birman  and  others  had  implemented  the  original  *Cast  and  iteratively 
evolved  it  over  time  [13],  and  the  expectation  was  that  the  scenarios  involved  in  Hopkin- 
son’s  experiments  would  easily  translate  into  a  model  of  JBIs.  However,  the  original 
*Cast  experiments  were  not  originally  designed  for  a  military  scenarios,  and  proved 
much  more  difficult  in  adapting  for  use  as  a  model  for  JBI.  This  appendix  section  dis¬ 
cusses  the  original  experiment  and  requirements  to  model  the  JBI,  and  the  source  code 
modification  and  development  needed  to  meet  these  requirements. 

A.l  From  Academic  Exercise  to  Operational  Environment 

The  original  *Cast  scenarios  supported  an  unconventional  topology  that  high¬ 
lighted  the  best  performance  features  of  the  *Cast  protocols.  Although  these  topologies 
were  simple  and  relatively  straightforward,  they  tended  towards  unusual  forms  that  did 
not  resemble  actual  networks  used  in  industry  or  defense.  Their  simplicity  was  geared 
towards  testing  the  protocol’s  abilities,  and  did  not  necessarily  reflect  an  actual  “real 
world”  application.  This  approach  is  pragmatic  and  efficient,  and  focuses  on  the  goals  of 
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Figure  A.  1:  Typical  *  Cast  Topology 

*Cast  research  in  the  academic  environment.  Atypical  scenario  topology  appears  in  Fig¬ 
ure  A.  1 . 

The  topology  consists  of  one  or  more  rings  branched  together  off  of  a  central  node 
in  a  start  configuration.  The  central  node  served  as  the  sender,  and  each  ring  served  as  a 
group  level,  as  described  in  Chapter  III.  The  links  were  simple  duplex  links,  and  modeled 
cable  lines  in  a  fixed  facility.  This  differs  from  what  was  required  to  model  a  JBI  envi¬ 
ronment,  described  in  the  scenario  section  in  Chapter  III.  Contrasted  with  the  topology  in 


Figure  3.1  (or  Figure  B.l  for  more  complete  representation),  the  required  topology  is  a 
much  more  complicated  hybrid  of  star  and  mesh  topologies  with  wireless  links. 

The  groups  in  the  original  *Cast  scenarios  were  non-specific,  as  they  did  not  need 
to  represent  any  real  data  stream.  Consequently,  all  agents  subscribed  to  all  groups  with 
the  same  interest.  Contrasted  with  the  table  of  interests  used  in  the  experiments  in  this 
paper  (Table  3.2),  the  much  simpler  table  of  interests  appears  below  (Figure  A.  1): 


Table  A.  1 :  Typical  Interest  In  Original  *Cast  Experiments 


Nodes 

Group 

Levels 

Group  1 

Group  2 

Group  3 

Group  4 

1 

1 

80 

75 

50 

25 

2 

1 

80 

75 

50 

25 

3 

1 

80 

75 

50 

25 

4 

2 

80 

75 

50 

25 

5 

2 

80 

75 

50 

25 

6 

2 

80 

75 

50 

25 

The  agents  that  appeared  in  the  original  *Cast  settings  were  uniform  and  did  not 
vary  between  group  levels.  The  interest  ratings  for  nodes  needed  to  expanded  to  support 
the  concept  of  multiple  units  with  varying  levels  of  interests  in  different  application 
streams  for  different  group  levels.  To  this  end,  different  node  types  would  have  to  be  cre¬ 
ated  with  separate,  customized  interest  ratings  that  would  characterize  a  unit  in  the  battle¬ 
field.  Achieving  these  customized  interest  ratings  was  necessary  to  simulate  JBI’s 
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scheme  for  prioritization  of  pub-sub  streams.  Again,  this  need  for  a  complex  interest 
structure  is  delineated  in  Table  3.2. 

From  a  conceptual  viewpoint,  the  translation  from  an  academic  environment  to  a 
military  scenario  appears  straightforward.  The  conceptual  shifts  involve  directly  translat¬ 
ing  nodes  in  the  original  scenarios  to  troop  units  in  the  JBI  scenarios,  grouping  like  troop 
units  into  group  levels,  and  expanding  the  interest  tables  to  support  a  wider  variety  of 
units  and  prioritization  for  application  streams.  From  a  development  standpoint,  there 
were  a  number  of  software  engineering  challenges  to  overcome. 

A.3  Software  Development 

The  primary  tasks  involved  with  molding  the  original  scenarios  into  the  one  re¬ 
quired  for  JBIs  were: 

•  Reconfigure  the  topology  from  the  academic  environment  to  the  military 
environment,  with  associate  unit  types  and  group  levels 

•  Support  the  implementation  of  multiple  node  types  with  customized  in¬ 
terest  levels 

To  achieve  these  goals,  the  current  software  architecture  for  executing  experi¬ 
ments  was  evaluated,  and  then  actions  were  taken  to  modify  or  replace  components. 

A.4  Original  *Cast  Scenario  Code 

The  process  of  executing  experiments  was  reviewed,  and  flows  similarly  to  the 
process  outlined  in  the  Process  section  in  Chapter  III.  An  illustration  of  this  process  ap¬ 
pears  in  Figure  A.2. 
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Figure  A. 2:  Original  *Cast  Scenario  Procedure 


The  boxes  marked  “C/C++  Scripts”  and  “PBcast  C/C++  code”  are  the  primary 
differences  between  the  new  process  used  in  Chapter  III  and  the  original  process  used.  It 
was  determined  that  these  were  the  two  components  that  were  to  be  modified  for  the  ex¬ 
periments.  The  latter  component,  the  PBCast  code,  was  modified  into  SBCast,  and  those 
changes  are  documented  in  the  SBCast  section  Chapter  III.  The  former  component,  the  C / 
C++  scripts,  is  the  subject  of  this  section.  The  C/C++  Script  was  responsible  for  creation 


of  the  topology,  group  levels  and  events,  so  it  was  targeted  for  modification  in  order  to 
accomplish  the  two  tasks  required  to  translate  the  scenarios  into  JBI  scenarios. 

The  C/C++  Script  was  the  script  generator,  and  it  accomplished  its  tasks  of  gen¬ 
erating  ns-2  topologies,  group  levels  and  events  by  outputting  expressions  of  the  topology 
in  Tel,  a  programming  language  that  the  ns-2  simulator  understands.  Tel  stands  for  “tool 
command  language”,  and  is  a  popular  language  in  use  by  Unix  applications.  Following 
the  explanation  of  the  experimentation  process  outlined  in  Chapter  III,  the  C/C++  Script 
contained  information  about  the  configuration  of  the  scenario,  and  wrote  Tel  scripts  for 
each  experiment  ran  based  on  this  information.  To  refer  to  Tel  used  specifically  for  ns-2, 
this  paper  uses  the  term  ns-2/Tcl.  It  is  possible  to  write  ns-2/Tcl  code  by  hand,  and  exe¬ 
cute  a  scenario  directly  by  manipulating  ns-2  manually.  This  approach  becomes  unfeasi¬ 
ble  when  scenarios  become  more  complex  and  multiple  trials  are  needed.  This  C/C++ 
Script  is  helpful  by  allowing  the  execution  of  large  volumes  of  trials  with  complex  sce¬ 
narios. 

The  initial  “easy  fit”  would  be  to  simply  modify  the  existing  C/C++  script  to  de¬ 
scribe  the  JBI  scenario.  For  purposes  of  utilizing  the  code,  an  initial  survey  was  done  to 
interpret  the  code  and  figure  out  what  precisely  it  does,  and  the  resulting  UML  diagram 
appears  in  Figure  A.3,  below. 

This  survey  revealed  that  the  code,  although  written  in  an  object-oriented  lan¬ 
guage,  was  highly  monolithic  and  procedural.  More  precisely,  the  program  consisted  of 
three  classes,  one  of  which  had  multiple  responsibilities  and  no  clear  order  or  schema  of 
their  functions.  The  class  in  particular,  the  GenScript  class  had  low  cohesion,  meaning 
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Generator 


FILE  'fileptr 
Int  i 

GenScript  script 
char**  coiorlndex 
char  ’path 
int  path  size  =  1000 
char ’new  path 
char  'script  name 
char  *mlab  path 
char  ’cornnd 
char  description^  000] 
int  nam.  switch 
int  ring  members[5] 
double  data  quality[5] 
int  num  error  entries 
double  'error  time 
double ‘error  rate 
int  num  trials 
int  trial 

int  trial  seeds[lO] 
int  mainO 
int  my  system(char  ‘command) 


GridUnit 

int  ID 
int  (lag 
int  rinc^ 


GridUnit**  mesh 
int  rings 

int  data  loss  entries 
double  ‘data  loss  times 
double  ‘data  loss 
double  round  time 
int  run  time 
int  num  nodes 
int  rand  seed 
char  “color  index 
int*  ring  members 
int  name  switch 
double  beast  start  time 
double  error  rate 
int  send  rate 

double  ’group  level  quality 
double  packet  timeout 
double  msg  timeout 
int  quality  calibration  interval 
int  num  quality  trials 
int  num  quailty  intervals 
int  msg  butter  length 


GenScript 


void  generate  mesh() 

void  set  send  rate(int  send  rate) 

void  set  group  level  quaiity(double  'group  level  quality) 

void  set  error  rate(double  error  rate) 

void  set  rand  seed(int  rand  seed) 

void  set  beast  start  time(double  beast  start  time) 

void  set  rings(int  rings) 

void  set  ring  membersfint  'ring  members) 

void  set  data  loss  entries(int  data  loss  entries) 

void  set  data  loss  times(double 'data  loss  times) 

void  set  data  loss(double  ‘data  loss) 

void  set  round  time(double  round  time) 

void  set  run  timefint  run.  time) 

void  set  color  index(char  “color  index) 

void  set  name  switch(int  nam  switch) 

void  set  packet  timeout(double  packet  timeout) 

void  set  msg  timeout(double  msg  timeout) 

void  set  quality  calibration  interval(int  interval) 

void  set  quality  calibration  tolerance(double  tolerance) 

void  set  num  quality  trials(int  trials) 

void  set  num  quality  intervals(int  num  quality  intervals) 

void  set  quality  start  time(doubie  ‘quality  start  time) 

void  set  msg  buffer  length(int  msg  buffer  length) 

void  generate  script(FILE  'fileptr) 

^oid>ger^rapt^cnpt(Fl^^fileptr^har^escription)__ 


Figure  A.3:  UML  Diagram  for  C/C++  Script  Generator 


that  it  implemented  too  many  methods  that  were  possibly  not  directly  related  to  the  class’ 
original  purpose  [16].  The  evidence  of  this  low  cohesion  is  in  GenScript’s  long  list  of 
methods  or  attributes.  This  resulted  in  the  GenScript  class  becoming  so  large  as  to  encap¬ 
sulate  the  majority  of  functions  to  define  the  topology. 
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This  was  a  daunting  obstacle  in  the  face  of  generating  the  JBI  topology  and  de¬ 
fining  group  level  interests,  as  the  design  obfuscated  the  definition  and  creation  of  the 
agents,  links  and  interest  settings.  The  form  of  the  code  made  the  script  non-modular,  and 
distinct  components  could  not  be  added,  removed  or  modified  discretely.  This  presented 
challenges  to  future  modification.  If  the  requirements  for  the  scenario  were  to  ever 
change  (which  it  did  frequently  during  the  course  of  this  thesis),  modifications  would  be 
tedious  and  take  days  to  accomplish. 

After  examining  the  C/C++  Script  generator,  the  decision  was  made  to  generate  a 
new  script  generator. 
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A.5  Ruby  Cast  Scenario  Script  Generator 

This  section  steps  through  the  process  by  which  the  new  script  generator  was  cre¬ 
ated.  It  outlines  the  thoughts  and  considerations  that  went  into  designing  the  script  gen¬ 
erator  to  create  a  more  flexible  network  model  to  test  SBCast  within  JBIs. 

It  was  determined  that  the  best  way  to  model  the  agents  in  the  network  would  be 
to  make  them  first  class  objects  in  an  object-oriented  design  (OOD)  schema.  Interpreting 
the  ns-2  documentation  and  example  ns-2/Tcl  scenario  scripts,  it  was  observed  that  the 
overall  schema  for  ns-2  was  actually  object  oriented,  and  utilized  inheritance  to  define 
objects  from  classes  and  super-classes[8].  Declarations  in  ns-2/Tcl  view  nodes,  links  and 
other  network  infrastructure  in  this  same  way,  so  this  object-oriented  approach  is  a  good 
fit.  The  original  C/C++  script,  by  comparison,  iteratively  loops  and  constructs  groups  of 
nodes  and  links  procedurally.  In  an  object  oriented  design,  the  nodes,  links  and  other  ns-2 
objects  would  simply  construct  themselves.  Following  an  object  oriented  design  schema 
would  also  help  in  breaking  up  the  larger,  low  cohesion  Generator  class  in  the  C/C++ 
script  into  highly  cohesive,  simpler  ns-2  objects  to  create  modularity  for  easier  mainte¬ 
nance  and  modification.  Considering  the  basic  model  for  ns-2,  the  first  model  for  the 
script  generator  looked  like  the  UML  diagram  in  Figure  A. 4. 

This  model  expresses  the  basic  components  of  an  ns-2  simulation,  as  well  as  de¬ 
fining  an  ns-2  superclass  that  all  ns-2  objects  inherited  basic  functionality  from.  Here,  the 
basic  components  of  an  ns-2  simulation  are:  a  node,  which  can  represent  a  computer  sys¬ 
tem  in  a  network;  an  agent,  which  can  represent  some  client  software  on  a  computer  sys¬ 
tem  in  a  network;  a  link,  which  can  represent  any  communication  medium,  from  ethernet 
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Figure  A.4:  Basic  ns-2  Object  Model 


cables  to  satellite  shots;  and  an  application,  which  can  represent  a  server  or  service  avail¬ 


able  on  a  network.  It  is  also  important  to  note  that  nodes  are  the  basic  ns-2  objects  that 


make  up  networks,  and  links  connect  nodes,  and  that  one  or  more  applications  or  agents 


are  attached  to  nodes.  In  addition,  all  ns-2  objects  possess  unique  ns-2  attributes  and 


functions,  so  their  subclass  definitions  were  also  populated  with  appropriate  attributes 


and  methods  that  expressed  corresponding  ns-2  attributes  and  functions.  The  core  mecha¬ 


nism  that  translated  the  models  into  the  ns-2/Tcl  code  that  would  be  interpreted  by  the  ns- 


2  simulator  was  the  tcldefine  method,  which  was  inherited  by  all  subclasses  of  the 
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ns-2  object.  This  method  enabled  all  the  ns-2  objects  to  “write  themselves”  into  the  ns-2/ 
Tel  script. 

Ruby  was  chosen  as  the  programming  language  to  implement  the  code.  Ruby  is 
an  object-oriented,  high-level  scripting  language  that  combines  the  object-oriented  fea¬ 
tures  of  Java  and  Smalltalk  programming  languages  with  the  fluid,  scripting  nature  of 
Perl [24],  It  allows  for  rapid  development  and  at  the  same  time  can  easily  employ  object- 
oriented  design  principles,  such  as  the  use  of  design  patterns  and  general  responsibility 
assignment  software  principles  (GRASP).  Design  patterns,  defined  by  Alexander,  are  a 
programming  paradigm  that  helps  improve  the  maintainability  and  reusability  of  source 
code  [2],  GRASP  principles  are  object  oriented  design  methodologies  make  object- 
oriented  code  more  efficient  by  ensuring  objects  and  classes  are  assigned  the  correct  re¬ 
sponsibilities  or  functions  [16].  Ruby  also  contains  a  number  of  built-in,  useful  utilities 
such  as  file  input/output  libraries  and  data  structure  manipulation  tools.  Ruby  provides  a 
good  fit  for  modeling  JBIs  because  it  allows  the  use  of  software  engineering  design  para¬ 
digms  and  advanced  data  structures,  two  factors  that  helped  overcome  the  lack  of  flexibil¬ 
ity  and  maintainability  found  in  the  original  C/C++  script  generator.  To  denote  its  use  of 
the  Ruby  programming  language  and  its  use  in  generating  *Cast  experiments,  the  new 
script  generator  is  referred  to  as  Ruby  Cast. 

To  use  more  than  the  basic  nodes,  agents,  links  or  applications,  ns-2  and  Tel  syn¬ 
tax  typically  uses  subclasses,  and  any  ns-2  object  is  often  a  subclass  of  another.  There¬ 
fore,  this  script  would  also  follow  this  same  design  rule,  and  so  the  specific  links,  nodes 
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and  agents  necessary  were  implemented  as  subclasses  to  the  basic  types  defined  above. 


This  leads  to  this  less  general,  more  specific  UML  model  in  Figure  A.5. 
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Figure  A.5:  Intermediate  ns-2  Object  Model 


The  important  takeaway  from  this  figure  is  that  the  PBCast  agent,  which  would 
implement  the  code  of  all  the  *Cast  protocols  in  the  ns-2  simulation,  is  a  subclass  of  the 
Agent  class,  which  in  turn  is  a  subclass  of  the  ns-2  objects.  This  is  the  custom  agent  that 
the  PBCast  source  code  generates.  In  addition,  the  Null  Agents  and  the  CBRs  also  appear 
in  this  version  of  the  model,  as  well  as  the  duplex  links.  Although  any  ns-2  object  can  be 
modeled  in  the  script  generator  in  this  way,  the  pragmatic  decision  was  made  to  imple¬ 
ment  only  the  subclasses  that  were  needed  to  express  the  JBI  scenario.  If  any  additional 
ns-2  object  were  needed  for  the  scenario,  its  code  could  be  easily  constructed  and  added 
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to  the  model  later.  This  power  and  flexibility  came  from  the  object-oriented  design  of  the 
script  up  to  this  point. 

One  mechanism  that  Tcl/ns-2  lacks  is  a  facility  for  modeling  topologies,  such  as  a 
star,  hub,  ring  or  mesh.  Such  a  mechanism  is  necessary  to  link  all  the  separate  nodes, 
links  and  agents  This  was  probably  not  incorporated  by  the  VINT  group  because  topolo¬ 
gies  are  so  wide  and  varied  that  it  would  not  be  trivial  to  implement.  However,  this  de¬ 
sign  decision  is  what  makes  using  Tcl/ns-2  code  to  make  complex  topologies  for  ns-2 
simulations  difficult  and  tedious.  It  forces  programmers  to  come  up  with  large,  complex 
iterations  in  order  to  link  nodes  together  to  form  the  topologies.  The  best  example  is  the 
C/C++  script  generator;  referring  to  the  diagram  in  Figure  A.2,  in  the  method  gener- 
ate_meshes,  the  script  utilizes  a  series  of  multi-dimensional  arrays  in  multiple  passes 
to  construct  nodes,  configure  their  attributes  and  link  them.  In  order  to  escape  the  ring 
topologies  established  in  the  original  *Cast  scenarios  and  use  the  meshes  needed  by  the 
JBI  scenario,  the  use  of  the  C/C++  script  generator  would  require  non-trivial  manipula¬ 
tions  of  the  double-nested  arrays  in  generate_meshes .  Rather  than  follow  this  ap¬ 
proach,  it  was  decided  to  actually  implement  topologies,  but  do  so  in  a  way  that  the  VINT 
group  had  not  anticipated:  the  topologies  would  be  implemented  using  a  composite  pat¬ 
tern,  a  design  pattern  that  consists  of  treating  member  objects  and  the  group  those  objects 
belong  to  uniformly  [9].  Basically,  this  allows  objects  to  be  of  the  same  class  and  contain 
objects  of  that  same  class.  In  this  case,  a  topology  super  class,  that  was  also  a  subclass  to 
the  ns-2  class,  was  created,  and  various  subclasses  for  each  of  the  topologies  was  created: 
a  star  subclass,  a  ring  subclass,  a  mesh  subclass,  and  so  forth.  Using  this  technique,  a  sce- 
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nario  could  be  created  with  a  topology  that  could  contain  either  nodes  or  other  topologies, 
which  in  turn  might  contain  their  own  nodes  and  topologies,  ad  infinitum.  An  example  of 
this  appears  in  Figure  A.  6. 


Figure  A.6:  Composite  Topology 
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In  Figure  A.6,  there  is  a  star  topology  at  the  center.  One  of  its  spokes  contains  a 
node,  and  the  other  three  contain  a  mesh,  a  ring  and  another  star.  The  UML  for  this  con¬ 
figuration,  added  to  the  earlier  UML  diagrams,  appears  in  Figure  A. 7 


Figure  A. 7:  Intermediate  ns-2  Object  Model  With  Composite  Topology 
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Continuing  with  the  overall  theme  of  allowing  the  ns-2  objects  to  define  them¬ 
selves,  a  topology  would  call  its  tcldef  ine  method,  which  in  turn  calls  the  tclde- 
f  ine  method  for  the  objects  it  owns,  all  the  way  down  the  chain.  Using  the  composite 
design  pattern  also  created  another  hook  into  the  *Cast  mechanisms:  as  a  result  of  nodes 
being  grouped  into  topologies,  that  same  topology  could  be  considered  a  group  level.  As 
a  result,  one  requirement  of  the  scenario  in  Figure  3.1  in  Chapter  III  was  met:  associated 
units,  meshed  physically  in  the  network,  become  a  group  level. 

At  this  point,  the  model  had  achieved  the  goal  of  bringing  the  scenarios  created  in 
the  original  *Cast  experiments  into  a  military  environment.  The  second  task  to  accom¬ 
plish  was  to  add  support  for  multiple  node  types  with  customized  interest  levels.  This 
means  being  able  to  model  specific  units  with  specific  priorities  for  specific  JBI  applica¬ 
tions.  For  example,  one  desired  result  would  be  generating  a  representation  of  an  F-22 
that  has  higher  priorities,  or  interest,  for  receiving  a  data  stream  involving  the  Air  Tasking 
Order  (ATO).  These  units  and  interests  are  tabulated  in  Table  3.2  in  Chapter  III.  This 
problem  contained  two  parts:  the  first  part  was  to  define  the  multiple  node  types  with  cus¬ 
tomized  interest  levels,  and  the  second  part  was  to  define  the  group  applications  that  the 
nodes  would  subscribe  to. 

For  the  first  part  of  the  problem,  the  objective  was  to  figure  out  where  to  encapsu¬ 
late  the  specific  interest  for  a  specific  unit.  There  was  no  clear  fit,  as  the  way  the  original 
PBCast  code  implements  interest  is  not  in  the  same  way  that  ns-2  implements  objects.  An 
extremely  procedural  approach,  interest  levels  are  implemented  as  a  massive  multidimen¬ 
sional  array  where  the  coordinates  identify  the  unit  that  posses  that  interest  in  a  particular 
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application  stream.  As  a  result,  the  class  that  would  contain  the  interest  needed  to  trans¬ 
late  between  the  object  oriented  design  of  ns-2  and  the  procedural  nature  of  the  PBCast 
code.  The  first  choice  was  to  implement  a  subclass  to  the  Node  class.  However,  it  was 
determined  that  solution  was  too  complex  and  error  prone,  because  the  *Cast  agent  at¬ 
tached  to  the  node  would  be  the  interface  for  *Cast  traffic,  data  would  have  to  be  sent 
back  and  forth  from  a  node  to  the  attached  agent.  The  next  choice  was  placing  the  inter¬ 
ests  in  a  subclass  of  the  *Cast  agent.  This  approach  would  be  too  difficult  to  implement, 
as  it  requires  multiple  subclasses  of  the  *Cast  agent.  Considering  that  there  are  four  *Cast 
protocols  being  tested  and  seven  different  unit  types,  this  would  be  labor  intensive  be¬ 
cause  twenty-eight  subclasses  would  need  to  be  created.  Additionally,  should  more  unit 
types  be  introduced  into  the  scenario,  a  corresponding  subclass  for  each  *Cast  protocol 
would  also  need  to  be  created. 

The  best  solution  was  found  by  applying  the  strategy  design  pattern  [12].  By  ana¬ 
lyzing  that  the  only  component  that  varied  were  the  set  of  interest  levels,  it  was  discov¬ 
ered  that  a  better  solution  would  be  to  implement  interest  strategies.  Interest  strategies 
would  be  fabricated  objects  that  would  encapsulate  the  interest  levels  for  a  particular  unit 
type  and  would  be  added  to  a  *Cast  agent  as  that  agent  is  being  defined.  When  the  script 
generator  builds  that  particular  agent  into  the  Tel  script,  it  would  reference  the  interest 
strategy  for  the  interest  level  values  and  allocate  that  interest  value  into  the  multidimen¬ 
sional  array  in  the  PBCast  code.  The  UML  for  this  design  is  shown  in  Figure  A.8. 
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Figure  A.  8:  Interest  Strategy  Model 

Use  of  interest  strategies  allows  the  identification  of  units  without  the  need  for 


multiple  node  or  agent  classes,  and  provides  access  to  interest  data  without  having  to  cre¬ 


ate  new  subclasses  for  *Cast  agents. 


The  second  part  of  the  problem,  the  objective  involves  defining  the  group  in  the 


scenario.  Like  the  interest  levels,  the  PBCast  code  implements  groups  in  a  non-intuitive, 


procedural  way:  groups  are  a  collection  of  multidimensional  arrays,  whose  coordinates 


define  the  group  and  its  subscribers.  Groups  also  do  not  have  an  equivalent  ns-2  object, 


either.  Basically,  a  group  is  an  array  that  contains  data  for  subscribers.  The  task  is  to  de¬ 


cide  what  class  would  best  encapsulate  this  data. 


Unfortunately,  no  currently  existing  class  in  the  model  would  fit  the  group  data, 


and  the  best  solution  was  to  fabricate  a  completely  new  class.  Since  the  group  is  not  an 


actual  ns-2  object,  there  was  no  need  to  make  it  a  subclass  of  ns-2  objects.  The  new.  The 
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class  would  be  utilized  by  group  levels,  which  are  basically  the  topologies.  From  these 


considerations,  the  result  is  the  class  that  hangs  off  of  the  topology,  in  Figure  A.9. 


Figure  A. 9:  PBCast  Group 


The  additions  of  the  interest  strategies  and  the  PBCastGroup  class,  the  collection 
of  classes  with  which  to  define  the  JBI  model  is  complete  (Figure  A.  10). 
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Figure  A.  10:  Ruby  Cast:  Complete  Model 


With  the  completion  of  Ruby  Cast,  the  capability  now  exists  to  generate  scenarios 
that  portray  a  JBI  environment  that  incorporates  multiple  types  of  nodes  with  different 
priority  levels  for  different  application  streams. 

A.6  Summary 

This  chapter  discussed  the  transformation  of  the  original  *Cast  testing  environ¬ 
ment  from  an  academic  environment  into  a  military  environment.  The  process  started 
with  an  evaluation  of  the  existing  scenario  script  generator  and  resulted  in  the  develop¬ 
ment  of  a  new  script  generator,  Ruby  Cast.  The  result  is  a  modification  of  the  process  as 
it  appears  Figure  3. 10  in  Chapter  III. 

In  the  end,  this  appears  to  be  a  long  and  complicated  task  that  results  in  code  that 
does  what  previous  versions  of  the  code  accomplished.  This  begets  the  question,  what 
benefits  are  derived  from  this  intense  re-engineering  effort?  Comparing  the  UML  dia¬ 
gram  for  Ruby  Cast  (Figures  A.9)  to  the  original  C/C++  script  generator  (Figure  A. 3)  the 
complexity  seems  to  have  increased  with  the  number  of  objects.  The  difference  is  the 
complexity  is  spread  over  multiple  classes  that  represent  concepts  in  the  problem  (ns-2 
objects  and  the  JBI  model),  and  the  result  is  that  the  identity  of  classes  and  the  functional¬ 
ity  is  more  easily  understood  and  is  more  easily  modified  and  extended.  The  benefit  is 
that  not  only  can  the  script  generator  generate  scenarios  for  the  current  *Cast  experiment, 
but  also  can  be  reconfigured  quickly  and  rapidly  to  support  any  changes  in  any  *Cast  ex¬ 
periment  in  the  future. 
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Appendix  B.  Supplementary  Diagrams 
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Figure  B.l  Scenario  Topology,  Expanded 
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